DO NOT REPLY [Bug 5201] New: Rsync lets user corrupt dest by applying non-inplace batch in inplace mode

samba-bugs at samba-bugs at
Mon Jan 14 22:01:18 GMT 2008

           Summary: Rsync lets user corrupt dest by applying non-inplace
                    batch in inplace mode
           Product: rsync
           Version: 3.0.0
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: core
        AssignedTo: wayned at
        ReportedBy: matt at
         QAContact: rsync-qa at

I originally reported this bug here:

I noticed that rsync will let me apply a non-inplace batch file in inplace
mode.  This corrupts the destination file if the batch file copies any data
forward (from earlier offsets to later ones).  Of course, the post-transfer
checksum detects the corruption and gives the "ERROR: <file> failed
verification" message, but rsync doesn't give the user a clue why the
corruption occurred.

I think rsync should at least warn the user and possibly refuse outright to
apply a non-inplace batch in inplace mode.  However, existing batch
files don't indicate which mode they were written in, and it would be nice to
let a user apply a non-inplace batch if it happened not to use
any forward copies.  Thus, the best thing to do might be to issue an error like
this the first time a forward copy is seen for each file
(followed, of course, by the post-transfer checksum failure):

rsync: error: batch file delta for <file> contains a forward copy, which cannot
be performed in --inplace mode (probably the batch file was written without
--inplace); the update will probably be corrupted

Here is a script that demonstrates the current behavior:

rm -rf src dest batch*
mkdir src dest
wget -O dest/file
head -c 1000000 /dev/zero | cat - dest/file >src/file
rsync --no-whole-file --only-write-batch=batch src/file dest/
rsync --inplace --read-batch=batch dest/


ERROR: file failed verification -- update retained.
(No batched update for "file")

Two additional problems seem to have arisen since my original mail to the list:

1. The inaccurate message `(No batched update for "file")' appears. 
Furthermore, in the case of a solo file, this message shows its source name
while the previous line shows its destination name, which seems inconsistent.

2. Rsync isn't exiting with code 23, which might mislead a script to think that
the copy was successful.

Configure bugmail:
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

More information about the rsync mailing list