Detection of permission changes

[Joachim Otahal (privat)]

Nope.

Available line speed: Sending 5 MBit, receiving 6 MBit. "real" line 
speed - well, it is a VPN over Internet, very "controlled" speed...... 
All files are already sync.

Fileset: about 3.31 GB, 3146 files, several runs.
min time/max time/mean time

rsync -rtvvzPc --compress-level=9 --fuzzy --delete-delay 
192.168.250.68::d/bootcd/ /cygdrive/e/bootcd/
sent 10497 bytes  received 145562 bytes  2039.99 bytes/sec
total size is 3559041255  speedup is 22805.74
75.4/96.3/80.8 seconds

rsync -rtvvzP --ignore-times --compress-level=9 --fuzzy --delete-delay 
192.168.250.68::d/bootcd/ /cygdrive/e/bootcd/
sent 8885025 bytes  received 207541 bytes  33613.92 bytes/sec
total size is 3559041255  speedup is 391.42
182/250/195 seconds

-c wins clearly over --ignore-times, about 5:2 (more or less).

--ignore-times would win if: some files with large size, change every 
time they are synced, but only 'cause -c only saves time on files that 
are already snyc. In my sync case > 95% of the files are already sync 
(except for my testing when everything was sync).

regards,

Joachim Otahal

Kevin Korb schrieb:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Try --ignore-times instead of --checksum.  It will appear to do more
> since it will actually re-delta xfer everything but in my experience
> that is faster than --checksum almost all of the time.
>
> On 03/02/12 02:07, Joachim Otahal (privat) wrote:
>> Kevin Korb schrieb:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>
>>> I am not much of a programmer so I know I could never take over
>>> rsync development but if I could boss such people around here are
>>> the new directions I would take:
>>>
>>> 1. --itmize-changes is eliminated and becomes part of --verbose
>> 100% agree there.
>>
>>> 5. I am almost tempted to say I would remove --checksum because
>>> 95% of the times I have seen someone using it they did so to
>>> their own detriment.  But I have seen at least 2 actual valid use
>>> cases for it to exist so I would only add an extreme disclaimer
>>> to the man page
>> Naaa, please not. I rsync some sets across a slower VPN line, and
>> due to different OS-es and filesystems on both ends I cannot rely
>> on things like timestamp. Checking filesize changes is not enough,
>> since quite some files (a few hundred of several thousands) change
>> without changing the size, and less than ten files (but too many to
>> ignore) get modified without changing the (a|c|m)time. This leaves
>> me the last resort -c to make 100% sure every change is detected,
>> but only changed files are synced.
>>
>> If -c would not exist I would be forced to use something
>> completely different, first sync "the usual way" based on filesize
>> and timestamp. I would not need rsync for that, simpler tools which
>> don't require a daemon can do the same. And in a second run do a
>> crc32 (or md5 whatever) recursive, check for crc differences and
>> transfer those which crc's still differ. Would work, but ugly. -c
>> is better and my absolute winner.
>>
>>> Unfortunately I know that such fundamental changes would create
>>> a backlash.  So maybe I wouldn't actually do them if I had the
>>> authority.  But I am pretty sure they are all a good idea.
>>>
>>> and of course now we are way beyond the scope of your question
>>> and into the realm of the opinion of someone who has been using
>>> rsync as the low level tool of a backup system for more than a
>>> decade and who regularly helps out on #rsync.
>> Oh yes indeed, your answers show a lot of experience fighting
>> with/against the rsync dragon.
>>
>> Joachim Otahal
>