https://bugzilla.samba.org/show_bug.cgi?id=7249
--- Comment #6 from don...@gmx.com --- +1 from here as well. I understand the arguments about the limited usefulness of the atime field in general, and I agree with much of it, but to me there are more use cases than what's mentioned in what I've read so far - such as providing helpful clues for certain kinds of "forensic" debugging. atime has been around for a very long time (every *NIX variant I've worked on, going back to the 1980's), so even though its utility may be a bit "specialized", there are clearly people who are surprised to see it ignored by a tool like rsync. IMO back-up/replication/sync tools should strive to record or replicate the "originals" as faithfully as possible[*], with minimal impact on the contents or meta-data of files being backed up or replicated. That is to say, one should ideally be able to use rsync to do things like moving a directory tree to a new place (file system, machine), or copying/sync'ing it to a back-up location, and later restoring the originals, without the user of those files being able to discern any differences in them. I built rsync with Nicolas George's O_NOATIME patch on the latest Git, and IMO this change brings rsync one step closer to that ideal (on Linux at least). It not only avoids clobbering the atime values for the original files as they're being read during a first copy operation, but also when they're being checksummed (on both sides) if one uses the "-c" option in a later re-sync. Martin von Gagern: That's the main reason that I think "--noatime" should be sent to the remote side. I agree that in some/many cases, rsync users would not care about atimes being preserved in the copy. For backups, supposing atimes had been copied to the backup machine[*] (perhaps not part of the scenario you had in mind), they would need to be preserved during re-syncs in order to be able to available when sync'd back to the original place during a restore. One problem with unconditionally sending a new option to the remote side is that if it isn't supported on the remote side, it fails, whereas I would still see benefit (for some use cases) in using O_NOATIME on the local side only in that case. Not sure how easy it would be to handle that situation. Aside from that, I would really like to see this enhancement be integrated as soon as possible. Since it's an option, and doesn't affect the protocol etc, it doesn't seem as though it would have any negative impact when it isn't being used. Seems like a win-win. :) Could it be integrated before the next release? [*] Which brings us to the --atime patch -- but that's another topic. -- You are receiving this mail because: You are the QA Contact for the bug. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
