definite data corruption in 2.5.0 with -z option

rsync at ka9q.net rsync at ka9q.net
Thu Dec 13 14:23:42 EST 2001


I just ran into the same corruption problem with 2.5.1pre3. Again, it
only happens when I use large checksum block sizes (65536) *and*
request compression (-z).

Because the corrupted file has a correct size and timestamp, I have to
re-run rsync with the --checksum option (and with either a standard
block size or no compression) to force the file to be correctly updated.

This time I did a diff between the corrupted file and the correct one.
It was a mail list archive in mbox format. Interesting how the same
error is made in several places, and only in one byte.

bash-2.03$ diff cryptography.bad cryptography
1476c1476
< From owner-cryptography-outgoing at wasabisystems.com  Tue DeF 11 09:23:27 2001
---
> From owner-cryptography-outgoing at wasabisystems.com  Tue Dec 11 09:23:27 2001
1731c1731
< From owner-cryptography-outgoing at wasabisystems.com  Tue DeF 11 10:32:26 2001
---
> From owner-cryptography-outgoing at wasabisystems.com  Tue Dec 11 10:32:26 2001
1807c1807
< From owner-cryptography-outgoing at wasabisystems.com  Tue DeF 11 15:07:53 2001
---
> From owner-cryptography-outgoing at wasabisystems.com  Tue Dec 11 15:07:53 2001
1930c1930
< From owner-cryptography-outgoing at wasabisystems.com  Wed DeF 12 18:59:52 2001
---
> From owner-cryptography-outgoing at wasabisystems.com  Wed Dec 12 18:59:52 2001

Phil






More information about the rsync mailing list