definite data corruption in 2.5.0 with -z option
rsync at ka9q.net
rsync at ka9q.net
Thu Dec 13 13:33:06 EST 2001
>Please keep the two directories that caused the problems, if they have
>not already been overwritten.
They've been overwritten, but the problem is easy to recreate.
I did diff the correct and incorrect versions of the file. A whole
bunch of instances of the word "for" were turned into "foF". Weird.
>Are you sure you're running 2.5.0 at both ends?
Yup.
>Are you using rsh or ssh?
Openssh-3.0.2p1.
After I sent my note, I ran some more experiments and found the
problem goes away if I use the default checksum blocksize. So the
problem occurs *only* if I use a large blocksize (65536) *and* enable
compression.
>David: I suspect this might be because the "bit length overflow"
>message is being emitted by one end, getting into stderr, and
>therefore corrupting the stream. If this is true, you should be able
>to avoid it by upgrading to 2.5.1pre.
I'll give that a try.
Phil
More information about the rsync
mailing list