On Fri, Jun 30, 2000 at 03:44:57PM +1000, Bradley M. Kuhn wrote:
> I made this proposal back in February. I never heard a response either
> way. I am willing to right this patch, but only if it has a chance of
> being accepted.
>
> Any comments from the rsync maintainers?
>
> ----- Forwarded message from "Bradley M. Kuhn" <[EMAIL PROTECTED]> -----
>
> From: "Bradley M. Kuhn" <[EMAIL PROTECTED]>
> To: Multiple recipients of list RSYNC <[EMAIL PROTECTED]>
> Subject: Re: Patch to make rsync preserve access times
> Date: Fri, 11 Feb 2000 06:01:56 +1100
>
> [EMAIL PROTECTED] wrote:
> > I know atime support would be useful for some people, but if it makes the
> > code much more complex to maintain then that is bad. If someone comes up
> > with a patch that adds atime support without adding huge amounts of code
> > then I'd look at it, but my guess is that this would be quite hard to do.
>
> My patch, I am guessing, probably added what you would call "huge amounts of
> code". :)
>
> I understand your concern with that. The only other way I found that I
> could add this is to do the following:
>
> 0. identify everywhere in the code that a files atime would be changed:
> (i.e., any open(), stat(), opendir() calls)
>
> 1. find out if open()'s, stat()'s and opendir()'s are done in a consistent
> fashion, and if not, set it up so they *are* done in a consistent
> fashion.
>
> In other words, make sure that we always use wrapper functions (such as
> rsync's do_open() and do_stat()) that we have control over. I don't
> believe it is the case that such operations always use wrappers right
> now; that's why it was hard to find all the places where access times
> were changed.
>
> 2. modify only those wrapper functions so that they add any files that
> were modified to one of two lists of files: (a) files accessed on the
> client side, (b) files accessed on the server side.
>
> 3. at the end of the rsync procedure, if the user requested access time
> preservation, then use the data collect in (2) to reset all access
> times in question.
>
>
> Steps 0 and 1 could be a patch by themselves. The bonus here would be that
> one would be able to consistently track which functions access any files.
> This would be useful by making file access that rysnc does more uniform, as
> well as making it clear when rysnc effects atimes.
>
> Steps 0 and 1 would probably create a somewhat large patch, but it would
> contribute to the overall maintainability of the code, so such a change
> might be worth accepting.
>
> And, if such a change were accepted, Steps 2 and 3 are only a minor change.
I'm not an official maintainer anymore, but I think steps 2 & 3 are a bad
idea because they would take up memory for every file that is read (which
admittedly is not normally most of the files because rsync usually skips
files whose timestamps match). Why not reset the access time immediately
upon close?
My guess is you'd have to actually implement your idea to show exactly what
changes will be needed before Andrew would consider it.
- Dave Dykstra
