The behavior of "-u/--update" option on directories

[Aaron W Morris]

On Mon, 2003-01-13 at 22:46, Florian-Daniel Otel wrote:
> 
> Aaron,
> 
> Aaron Morris writes:
> > rsync is just doing what your are telling it to do.  Update if the file 
> > is changed or does not exist on the remote side and delete if it no 
> > longer exists on the local side.  
> 
> Yes, I can RTFM, and, suprisingly!, I  even _did_ RTFM :)).
> 
> > The directory may have a newer 
> > timestamp, but you are doing a recursive put so it has to check all the 
> > files and dirs under each directory.  At least that is how I see it.
> > 
> > solution:  --exclude "/tmp/"   or   --exclude "tmp/"
> 
> Well, I think you missed the point. The "tmp" subdir was just an example. The
> same can happen in any subdir down the tree. And, if you re-read my
> post carefully (or even the subject), I said "--update" (mis)behavior
> __on_directories__ (and _not_ regular files).
> 
> Truth to be told, after a bit of thinking I _might_ accept the fact
> that "--update" ignores the timestamps on (sub)directories. Because
> if it didn't, if any file was "touch"-ed remotely after the last rsync
> than all subdirs,  up to and including to the "top" dir, would have a
> newer timestamp remotely and thus no file putting would take place.

This is usually the case, however, not always true.  It is possible for
a file to have a newer timestamp then the directory it is contained
within.  If we used your logic below, then a file with a newer timestamp
(possibly changed data) on the source would not be transferred to the
remote machine if the source directory's timestamp did not change.

> 
> However, I still think that "--update" (or, ideally,  another similar
> option or combination of options)  __should__ take into account
> (sub)directories timestamps and consider for processing only those
> (sub)directories that have remotely an older timestamp than
> locally. 
> 
> Or, to put it in your words "...doing a recursive put should
> be restricted __only__ to the (sub)directories that remotely have a
> timestamp older than locally". If that means that _no_ update
> (i.e. put) will take place because __any__ file deep down the tree was
> touched remotely since the last put...well, than that's it.
> 
> Again, thanks in advance to  anyone can suggest a way to have rsync
> __also__ in this way.
> 
> Best regards,
> 
> Florian
> 
> 
> > Florian-Daniel Otel wrote:
> > > Dear all,
> > > 
> > > I have the following problem: I use the following command to "push"
> > > files from "local" to a "remote" machine:
> > > 
> > > [...]
> > > /usr/bin/rsync -avuz -e "ssh -1" --exclude ".Xauthority"  --delete  /user/home/directory/  user at remote.machine.name:/user/home/directory/ ;
> > > 
> > > (The ssh is using RSA authentication btw. machines,  but that's beside the point).
> > > 
> > > The problem:
> > > 
> > > 
> > > On both the local and remote machines there is a subdirectory
> > > "/user/home/directory/tmp". If on the remote machine that subdirectory
> > > has a newer time stamp  -- e.g. due to a file that was created
> > > recently i.e. after the last time the local machine did a "pull" --  the
> > > "--delete" option in the command above makes it such that the said
> > > newer file is deleted on remote and the timestamp is reseted back to
> > > the old time stamp i.e. the one for the "tmp/" subdir on the local machine.
> > > 
> > > 
> > > Putting it shortly, the "--delete" option has precendence over "-u"
> > > option w.r.t. directories. 
> > > 
> > > Is it so that "-u" works only on files and not on directories ?
> > > IMHO the appropriate behaviour in a situation like the one described
> > > above directories on remote that have newer time stamp  should be ignored 
> > > and excluded from further processing (i.e. including updating and/or
> > > deleting any files that do not exist on the local machine).
> > > 
> > > The question:
> > > 
> > > Am I right and that is the way things should behave and I am doing
> > > smth wrong ? If not, and this is the way things are supposed to work,
> > > can anyone suggest a work-around that would simulate the desired behavior ?
> > > 
> > > 
> > > 
> > > Many thanks in advance,
> > > 
> > > Florian
> > > 
> > > P.S. Please Cc: me on the replies, I'm not on the list. Thanks. 
> > > 
> > > P.P.S: If it matters: In the above setup the "local" machine is a
> > > Linux running "rsync  version 2.5.4  protocol version 26" whereas
> > > "remote" is a Solaris 2.8 running "rsync  version 2.5.5  protocol version 26". 
> > > 
> > 
> > -- 
> > Aaron W Morris
> > decep
> > PGP Key ID:  259978D1
> > 
> > 
-- 
Aaron W Morris
decep
PGP Key:  259978D1