1.5.13-1 rsync data corruption

[Keith Moore]

I'm trying to use rsync/ssh under Cygwin 1.5.13-1 to backup my Windows
box to my Linux box. The initial (full) backup works great, but
subsequent incremental backups fail on certain large files when
compression (-z) is enabled. So far, the problem only appears when
making incremental backups of VMware virtual disk images. Note that
these images are large (exactly 4G each), somewhat sparse (lots of
zeroed sectors) and VMware is *not* running during the backup.

I've reproduced the problem when backing up from my Windows box to my P4
desktop (running Fedora Core 3 with all updates), and from my Windows
box to my Kuro box (a small embedded PPC system running a hacked-up 2.4
kernel). I have (so far) been unable to reproduce the problem when
backing up the exact same files between these two Linux boxes.

I've focused the test case so that I don't have to backup my entire
system to duplicate the problem, which appears to be easily reproducible.

For the full backup, I execute:

rsync -aPvz /cygdrive/d/test/ \
abstruse:/usr/backup/test.full

This works as expected. Next, I run VMware briefly so the disk image
will get "slightly" modified, then I perform the incremental backup:

rsync -aPvz /cygdrive/d/test/ \
--link-dest=/usr/backup/test.full \
abstruse:/usr/backup/test.inc

This produces a "failed verification" message from rsync.

My /cygdrive/d/test/ directory contains two small Perl scripts and a one
of the 4G disk images.

The form of the data corruption is interesting. The resulting file (on
the server) is *mostly* correct. However, a small number (150 or so)
blocks of data have a single 0xED byte where they should have 0x00. This
appears to always happen at the end of a 0x200 byte block. On my last
test run, the first byte of corruption was pretty far into the file --
at the end of the 1,177,356th 1024-byte block.

Omitting the "-z" switch to rsync appears to mask the problem.

I've tried unsuccessfully to reproduce the problem using a 4G random
file (dd if=/dev/urandom of=foo bs=1K count=4M). This makes me suspect
the problem is some data sensitivity in the compression library.

If there is any information I can provide, or any other tests I an try,
please let me know.

KM
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cygcheck.out
URL: <http://cygwin.com/pipermail/cygwin/attachments/20050315/bda20102/attachment.ksh>
-------------- next part --------------
--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/