Patch to make rsync preserve access times

[Gilbert E. Detillieux]

According to Dave Dykstra:
> I've been a vocal opponent to adding a preserve access times option to
> rsync.  I have been bitten numerous times by a cpio -oa process that system
> administrators have set up for making incremental backups, because it
> resets the inode change time which I find to be of far greater value.  The
> inode change time itself is important for incremental backups, because if
> somebody renames a file without accessing it or modifying it, it still
> should be backed up under the new name.

I hadn't considered the interaction of this feature with the possibility of
incremental dumps (by some other means) being done on the same source files.
Your point is correct, in as much as the two wouldn't mix.  However, this
just means that the option to preserve access times should not be used in
such cases.  There are still cases where the use of this feature _would_ be
useful, as long as incremental dumps of the source files aren't relied upon.

The fact that there's a potential for danger in its use is not sufficient,
IMHO, to not allow this feature to be added to rsync.  The info file for GNU
tar, for example, points out the incompatibility between --atime-preserve
and incremental backups, rather than disallowing or not implementing one of
those incompatible features.

> I wasn't sure if the -a option worked for cpio -i, to restore an access
> time from an archive, so I just tried it.

No, since the cpio header format doesn't allow for the transfer of atime,
there's no way for the input side (doing the extraction) to know what the
times were on the output side (doing the reading of the source files).  GNU
tar also doesn't pass along atime in the headers (presumably for reverse
compatibility), except in the case of incremental backups (ironically), in
which case we can't really make use of access time preservation.

The fact that neither of these do the whole job right is one of the reasons
I was really hoping to use rsync for the job.

>  On Solaris 7, it reset both the
> modification and access times to midnight January 1, 1970!

The cpio command in Solaris is broken in a number of ways.  (I didn't
realize the above bug was in there, though.)  For example, it won't allow
both the -m and -a options in conjunction with -p, although such usage
should be allowed (since -a applies to file being read, and -m applies to
files being written).

>  GNU cpio gives
> a usage message if you try to use -a with -i; the long name for the -a
> option is called --reset-access-time which works with cpio -o, but there is
> no -a or --preserve-access-time option for cpio -i.
> 
> So cpio can keep access times alone on the input side but will not send
> them through to the output side.  I don't think rsync should either.  If
> the files have been copied, they've been accessed so I don't think it's
> a big deal if the access time has been updated.

Well, I disagree with you there.  The fact that neither tar nor cpio allows
for access time preservation on both source and destination sides is not
sufficient reason to not allow it in rsync.  On the contrary, implementing
it in rsync in the way the patch does provides a useful capability that
cannot readily be added to either tar or cpio.

I also don't follow your logic in the last sentence.  Are you referring to
the source files?  In that case, your comparison to cpio breaks down, as it
does implement that half of it.  If you mean the destination files, I don't
see why their access time shouldn't be preserved.

The controversy seems to be surrounding the unfortunate side-effect of the
ctime being changed on the source side, which interferes with the correct
operation of incremental backups.  On the destination side, ctime will be
changed in any case, with or without access time preservation.  That may be
unfortunate in cases where ctime preservation would be useful too, but
that's a whole other issue, and there's currently no way to implement that
under UNIX.

My point is that it's not this patch that breaks that.

> > Some people may be concerned about the mods to ctime, which can hardly be
> > avoided, but I don't see that being a problem in practice.  I'm already used
> > to ctime being changed at the drop of a hat, and don't find them reliable
> > for much.
> 
> I've had the opposite experience.  Ctimes are the only reliable way to find
> out when a file has had some change made to them, and atimes aren't useful
> for much.

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!

I see your point about there being cases where ctime is important, but since
rsync doesn't (and can't) do anything to preserve those on the destination
anyway, it's kind of a moot point as far as rsync usage is concerned.  If
ctime preservation on the source side is important, then the --acess-times
option should not be used.  This could be made clear in the documentation,
if you're concerned about users being burned by it.

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.

> What are you using the access times for?

One application I have in mind for rsync with this feature is for mirroring
our incoming mail spool, while still preserving atime (and mtime) on both
the source _and_ destination.  We've found incremental dumps to be of
limited value in this case, and we want to be able to do restores with a
finer granularity than our overnight backups would allow.

As for using access times in general, I've got some cron entries that look
for files not accessed in a long time.  There are also things like the
tmpwatch command, found under Red Hat Linux (and possibly other distros),
which relies on atime to decide which files can be safely removed.

-- 
Gilbert E. Detillieux		E-mail:	<gedetil at cs.umanitoba.ca>
Dept. of Computer Science	Web:	http://www.cs.umanitoba.ca/~gedetil/
University of Manitoba		Phone:	(204)474-8161
Winnipeg, MB, CANADA  R3T 2N2	Fax:	(204)474-7609
"Cautionary tales don't end with 'It was SO COOL!'" - Malcolm in the Middle