-----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. ke...@futurequest.net (work)
Orlando, Florida k...@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-----
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
