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

Aaron Morris aaronmorris at mindspring.com
Mon Jan 13 20:23:00 EST 2003


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.  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/"

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





More information about the rsync mailing list