Under circumstances that are not fully understood but appear to be related to the presence of a transfer and a deletion in a previous directory, rsync 3.0.7 sometimes reports a checksum mismatch for files whose contents are in fact identical on source and destination. Original report by Mikolaj Kucharski: https://lists.samba.org/archive/rsync//2011-January/025988.html A minimized test case: mkdir src src/sub touch src/1 src/2 src/sub/file rsync -a src/ dest/ echo data >src/1 rm src/2 rsync -nvi -rc --delete src/ dest/
Indeed. Switching from --delete to --del is enough to avoid the issue. Will investigate.
Actually, the bug seems to be somewhat random, so the vanishing of the issue with --del was just a random no-show.
A work-around for this issue is to always use the --owner (-o) option with --delete when using incremental recursion. I'll work up an actual fix soon.
This will be fixed in 3.0.8.
The underlying bug here has potential security ramifications, so I was holding off on adding the full story until rsync 3.0.8 was released with the fix. Briefly: if --recursive, --delete, and --hard-links are on and --owner is off, a malicious sender can cause the receiver's hard-link data structures to become corrupted so as to break memory safety. I've demonstrated that this can lead to heap corruption; arbitrary code execution has been neither confirmed nor ruled out. (Some sites are claiming arbitrary code execution is known to be possible; that is incorrect, unless they know something I don't.) You can read more at https://bugzilla.redhat.com/show_bug.cgi?id=675036. See also the CVE entry at https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1097.