Re: The behavior of -u/--update option on directories
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/ [EMAIL PROTECTED]:/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 -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: The behavior of -u/--update option on directories
Aaron W Morris writes: 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. Hmm..well, while a possible scenario for that to happen doesn't come right off the bat, I cannot disagree with you there. Still, I find this as a rather shoddy justification for the present behavior of the --update (i.e. the fact that in effect the timestamps on (sub)directories are practically ignored). Frankly, I would rather want to have the choice. To get a bit more constructive: Any idea how can I simulate the behavior I want ? Or am I simply left w/ the option (sic!) of voicing this as an (exotic ?!?!?) wishlist item :) ? Thanks anyway, Florian -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: The behavior of -u/--update option on directories
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/ [EMAIL PROTECTED]:/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 -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: The behavior of -u/--update option on directories
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/ [EMAIL PROTECTED]:/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 -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
