propagate atimes with rsync-2.6.6 (fwd)

[Wayne Davison]

On Tue, Jan 24, 2006 at 05:46:36PM +0100, Christian Konz T3 wrote:
> Therefore, we have created a modified version of rsync based on
> rsync-2.6.6 protocol version 29 which transfers the access times with
> the transferred files and also allows to preserve the access times on
> the sending side.

First -- thanks for the patch.  You've unfortunately duplicated some
work that was already done (see the file patches/atimes.diff in the
rsync source), but your version does do things a little differently:

- The atimes.diff patch does not require a protocol bump because the
  new behavior is not enabled by default; it is turned on via the
  --atimes (-U) option.  (I personally don't think that preserving
  the atime should happen by default, not even with -a.)

- The atimes.diff patch omits directories from its access-time
  preservation (since it is very likely that the atime on directories
  will change outside of rsync's control and some systems don't like
  the atime to be forced on a directory).

- The atimes.diff patch adds a new XMIT_SAME_ATIME flag that avoids
  sending the same atime value twice in a row (just as the regular
  code uses XMIT_SAME_TIME for the mtime value).

- The atimes.diff patch changes the output of --itemize-changes when
  --atimes is specified to indicate which files needed an access-time
  change.

- Your patch has an option for leaving the access time unchanged on
  the source where the atimes.diff patch does not (though see below
  for my comments on this).

The main reason that the --atimes option has not made it into the main
source is that I was not willing to increase the amount of per-file
memory needed to make room for a value that most people didn't need
(since the preservation of access times is not commonly required).
However, I recently modified the atimes.diff to make it only use extra
memory when the --atimes option was actually specified, so I am
considering adding the option to the next version (its inclusion now
mainly depends on if I consider this memory-saving design too much of
a kluge or not).

Here are some comments on your patch:

- Your code should not be checking the remote_protocol variable, but
  the protocol_version variable.  This is because the negotiated
  protocol version can differ from the maximum remote value (mainly
  by the use of the --protocol option).

- You have code that sets the atime on a file that was hard-linked
  via --link-dest.  This is probably the right choice (and one that
  the atimes.diff patch fails to consider):  it can mean that older
  version(s) of identical files can get the access time updated, but
  it's probably not an important enough of a difference to force a
  new version to be copied into the destination (rather than
  hard-linked to a --link-dest version).
  
- Your change in set_perms() only sets the atime if the mtime differs.

- Your patch's optional preservation of the access times on the
  sending side is done by forcing both the access time and the modify
  time to the values that were acquired at the start of a file's
  transfer.  This can be unsafe if someone managed to change the file
  during the time that the file was being sent.  You should at least
  re-stat the file at the end of the transfer to make sure that the
  modify time hasn't changed (and skip the update if it has).  Even
  then, I'd be uneasy about this method of trying to leave the access
  time unchanged on the source because there would still be a chance
  that it would obliterate an updated mtime.

Overall you did a very nice job of changing the code.  Thanks again
for helping out.

..wayne..