Patch to make rsync preserve access times

[Martin Pool]

[The mailing list was temporarily down, but should now be flowing
again.  Messages were only delayed, not lost, as far as I know.]

Another objection to preserving atime is that you can't reset it on
files which you do not own, even if you have write access, unless
you're root.  So again the behaviour may be a bit confusing in the
common case of a nonprivileged user copying a directory with diverse
ownership.

There are two race conditions with respect to resetting the time: the
first, which I think was already mentioned, is that if somebody else
accesses the file while it's being copied the reset will go back too
far.  This is possible a problem for mail spools or temporary
directories.

Another is that utimes() takes a filename, not a handle, so if files
are renamed underneath us the wrong file might be updated.

> So, in those cases, access time preservation, which is an _optional_
> feature, doesn't have to be used.  However, for those that would
> find it useful, having such an option would be a good thing.
> Everybody wins!

... except the people burnt by confusing or inconsistent behaviour.
If you consider the tmp-cleaner case you mentioned, then it's entirely
possible that the atime patch might cause active files to have their
atime inadvertently preserved and to therefore be deleted.  If both
rsync and some other job that touches temp files are started from a
script then the timing might well be right.

> However, the potential for being burned is not sufficient reason to disallow
> a useful feature.  Otherwise, we'd all be using far more restrictive systems
> than UNIX, which is replete with powerful tools that can do damage if abused.

Right, but you could equally well argue that Unix ought to have
O_NOATIME.  Getting rid of most restrictions doesn't mean you have
none. 

I'm not completely hostile to the idea, but I'm just not convinced.
If we merge it I think it is very likely to generate more support
questions about the inconsistencies.  I also think the code is
enormously crufty at the moment and it really doesn't need more
features rammed in.

--
Martin