Detection of permission changes

Kevin Korb kmk at
Fri Mar 2 08:22:57 MST 2012

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:
>> 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

- -- 
	Kevin Korb			Phone:    (407) 252-6853
	Systems Administrator		Internet:
	FutureQuest, Inc.		Kevin at  (work)
	Orlando, Florida		kmk at (personal)
	Web page:
	PGP public key available on web site.
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the rsync mailing list