Detection of permission changes
Joachim Otahal (privat)
Jou at gmx.net
Fri Mar 2 00:07:18 MST 2012
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
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.
More information about the rsync