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