On 1/19/2013 1:28 PM, Nicolas Thierry-Mieg wrote:
Reindl Harald wrote:
Am 19.01.2013 15:46, schrieb Nicolas Thierry-Mieg:
M. Fioretti wrote:
On Fri, Jan 18, 2013 08:07:40 AM -0500, SilverTip257 wrote:
if you really want to eliminate that data being transferred, I suppose you could do the extra work and rename the directory at the same time on the source and destination. Not ideal in the least.
Not ideal indeed, but I'll probably do it that way next time that some renaming like this happens on very large folders. I assume that after that, I'd also have to launch rsync with the options that says to not consider modification time.
no I don't think you will, since the file modification times won't have changed.
and even if the did - who cares?
- rsync does not transfer unchanged data ever
- rsync will sync the times to them from the sources
- so have nearly zero network traffic
Not true: if you change the modification time on a file, by default rsync will copy the whole file again.
See man rsync: Rsync finds files that need to be transferred using a “quick check” algorithm (by default) that looks for files that have changed in size or in last-modified time.
and yes I've tested this before posting ;-)
to avoid this you need to use --size-only .
Yet size only is not reliable. If for instance you have a simple text file with the word hellO and someone catches the typo and changes it to hello, the filesize doesn't change as near as I can see. Both show as 6 using ls -al. Unless rsync uses a more granular check of filesize that I am not aware of? If this is the case, then someone could potentially edit a large document fixing numerous simple typos and wind up with the same filesize.