Patch to make rsync preserve access times

[Dave Dykstra]

On Tue, Sep 04, 2001 at 04:50:02PM -0500, Gilbert E. Detillieux wrote:
...
> >  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.

I was referring to the destination files.  If files have been copied to
a new place, they have been accessed so I don't see why their access time
*should* 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.

Yes, my main objection is on the source side, and I wouldn't want it to
preserve the ctime.

...
> > 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.

I don't see why not preserving access times for that scenario would be a
big deal.  Mail files are accessed constantly.


> 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.


It seems to me the main reason why people want access times preserved is
for looking to remove old files, but that is really quite an unreliable
approach.  I find ctimes to be more reliable for that in many cases.


Like Martin, I could perhaps be pursuaded to change my mind, but currently
I'm not convinced.

- Dave Dykstra