Add atime and mtime support for files ops, start with files.put #1372
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…pport Add a restricted analog to the ``touch`` command. Supports mutating atime and mtime, however only allows modification of one time field at a time. A single unambiguous datetime val is the time source since any ``touch`` operation with specified atime/mtime requires the month, day, and time at a minimum. Is BSD aware in that datetimes are always converted to UTC rather than relying on the richer timezone support in GNU ``touch``. The single time field setting approach is less flexible per invocation than native ``touch``, but also far simpler and nicely fits with file operations and their way of working on a single attribute at a time.
Time metadate updates are not coalesced, as ``touch`` can do with a single date and time arg, or via reference files. However, this actually allows more flexibility than native ''touch`` by allowing both atime and mtime values to be specified independently. Two support functions are added as well.
Negative timestamps are valid and permissible. Ensure pyinfra.facts.files.stat doesn't fail to match stat command output when such values occur.
….files
In preparation for tests of mtime and ctime support, make the mock os.stat
actually use any stat fields provided in the test json, with non-zero defaults
for all fields.
Doesn't break any existing test, but lays foundation for any future ops or facts
which may use this info.
Doesn't currently support setting the st_{a, m}time_ns high-resolution time
fields.
Change the datetime Python value to be generated from the fromisoformat method rather than strptime. This yields identical results as before when no UTC offset information is provided, but respects it if it does. It is also consistent with the os.stat parsing.
Add several testcases to cover multiple aspects of functionality: - Change detection, incl. differences <1s that are visible in the seconds vals - Separate actions on mtime and atime - Local files as the time references - Remote files as the time references - Use of the server's timezone when a datetime arg has no tzinfo
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add concrete support for
atimeandmtimechecking/setting in thefiles.putoperation and provide infrastructure to add this time metadata support to other operations as well.Includes a fix in
facts/piles.pyto accommodate negative timestamps fromstaton the remote host.Added support for more
os.stat_resultfile metadata to be provided in the test json files, by updating the mockos.statpatch used for testing. This includesatime,mtime, but also the other members of the standardstat10-tuple as well.@Fizzadar: Looking for any feedback/implementation concerns, style changes you'd like, and how best to handle documenting the specifics and caveats. I added a note in the operation docstring, but if
atimeandmtimesupport is implemented in other operations (e.g.,files.file) these will be true there as well. Is there a preferred way to break that information out into something outside of the function-specific docstring?The expanded mock
os.statadded a fair number of LOC, but it's also now equipped for future features/higher fidelity.Also, I used the American spelling of "normalize" in one of the added support functions, happy to change it to British if preferred.
3.xat this time)scripts/dev-test.sh)scripts/dev-lint.sh)