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