propagate atimes with rsync-2.6.6

[Matt McCutchen]

On Thu, 2006-01-26 at 01:12 -0800, Wayne Davison wrote:
> 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.
>
> - 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.[...]

My personal stance on file times is as follows.  A file's mtime is a
useful counterpart to its data because it identifies the version of the
file; two files with identical names and mtimes are very likely to have
identical data (as rsync's quick check assumes).  Thus, mtimes should
usually be kept with data and preserved when a file's data is copied.
On the other hand, atime and ctime have hardly any use to normal users
and should be available only to the owner of the filesystem for forensic
purposes, if at all.  I especially have trouble with atime because
"reading shouldn't write".  Thus, all my computer's filesystems are
mounted noatime, and all my files on my computer and others' computers
carry the ext2 attribute A.

Enough digression.  While I don't have any desire to copy atimes to my
backups, others might want this feature, so we might as well add an
option to rsync.  On the other hand, the issue of changing back or
leaving undisturbed the atimes of the source files has been discussed
extensively on the tar mailing list.  The thread starts here:
   http://lists.gnu.org/archive/html/bug-tar/2005-09/msg00035.html

Summary: For a while, tar has supported setting atimes back with
utime(2).  The new O_NOATIME option to open(2) provides a better way:
one can open a file one owns without disturbing its atime.  However,
O_NOATIME only works on some kernels; on others, it is silently ignored.
I think tar can now be told to use one method or the other or to try and
figure out whether O_NOATIME works and then act accordingly.
-- 
Matt McCutchen, ``hashproduct''
hashproduct at verizon.net -- http://mysite.verizon.net/hashproduct/