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.


Andrew, how do you feel about this approach?  It will take some time, so I
won't go ahead with it until it has your blessing (in theory, at least :).


-- 
         -  [EMAIL PROTECTED]  -  Bradley M. Kuhn  -  [EMAIL PROTECTED]  -
                          http://www.ebb.org/bkuhn



----- End forwarded message -----

-- 
Bradley M. Kuhn  -  http://www.ebb.org/bkuhn

PGP signature

Reply via email to