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.
--
John Hinton
877-777-1407 ext 502
http://www.ew3d.com
Comprehensive Online Solutions
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
