On Fri, Sep 01, 2000 at 01:22:10AM -0400, Bradley M. Kuhn wrote:
> Dave Dykstra wrote:
> > Someone posted a similar patch back in February and Tridge and I were both
> > pretty opposed to it.  See the thread beginning at
> > 
> >     http://lists.samba.org/pipermail/rsync/2000-February/001787.html
> 
> I was the one that posted the patch.
> 
> One of the problems that Dave and Tridge had was the amount of changes that
> were required to make it work added too much complexity to the code.
> 
> The problem I had in developing the code is that atimes had to be fixed for
> every file is touched, each time it's opened.  
> 
> I proposed that we go to a system where do_open() and do_close() were always
> used instead of fopen/open and fclose/close, and that way you could put the
> atime handling code in those functions and even compile it out via ifdef's
> if needed.
> 
> If everywhere in rsync, do_open() and do_close() were used consistently,
> atime support would be a trivial patch.
> 
> Dave and Tridge seemed ambivalent about the idea of consistently using open
> and close wrapper functions, so I never spent the time to do a patch, as it
> required a lot of work, and I didn't want to bother unless I knew it had a
> good change of being accepted.


It doesn't seem to me like that is the Right Way to do it, but I really
don't know.  I think we said we'd have to see how it looked in the final
implementation to see if it seemed clean or not.



> I think that rsync should provide the *option* to do atimes, and I think
> it'd be useful too, if one could look at the code and easily add in hooks
> for every place a file is touched along the way (which could be done if
> wrapper functions were consistently used for opens and closes).
> 
> Anyway, that's my $0.02.  I am willing to collaborate with anyone interested
> in working up a better patch that Tridge and Dave might accept.
> 
> 
> > I think inode change times are much more valuable than access times.
> 
> Sometimes they are, sometimes they aren't.  I think the user should have a
> choice.


I would probably be satisified if the option name made it unlikely for somebody
to naively choose it, something like
    --preserve-atimes-instead-of-ctimes
Even that doesn't make it clear that we're talking about the *input* files
and not the output files; all the other options apply to what appears on
the output side.

- Dave Dykstra

Reply via email to