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


More information about the rsync mailing list