Detection of permission changes

[Kevin Korb]

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

- -- 
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
	Kevin Korb			Phone:    (407) 252-6853
	Systems Administrator		Internet:
	FutureQuest, Inc.		Kevin at FutureQuest.net  (work)
	Orlando, Florida		kmk at sanitarium.net (personal)
	Web page:			http://www.sanitarium.net/
	PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9Q5dAACgkQVKC1jlbQAQdANACfWdnSR9/MNymThE48SnB4bwPu
okIAnRKreRrN/Gg98jrBvL2LYzpI7ztn
=Pq+h
-----END PGP SIGNATURE-----