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

[Florian-Daniel Otel]

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.

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