DO NOT REPLY [Bug 4834] New: --inplace with --backup --backup-dir does not work

samba-bugs at samba-bugs at
Mon Jul 30 11:29:23 GMT 2007

           Summary: --inplace with --backup --backup-dir does not work
           Product: rsync
           Version: 2.6.9
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: core
        AssignedTo: wayned at
        ReportedBy: joost at
         QAContact: rsync-qa at

I believe this error still exists in version 2.6.9. Here's an example which
will fail:

rsync -av -b --inplace --backup-dir backup1 /tmp/rsynctest/test
root at server:/raidset1/rsynctest/
building file list ... done
rsync: open "/raidset1/rsynctest/backup1/test": No such file or directory (2)

sent 63 bytes  received 20 bytes  33.20 bytes/sec
total size is 114  speedup is 1.37
rsync error: some files could not be transferred (code 23) at main.c(980)

When I create 'backup1' manually on the receiver side, it will just work fine.
Without the inplace parameter, these dirs are created by rsync, thus working as
expected. So, with the inplace parameter, it seems that backup file gets copied
if it's underlying dir exists, otherwise it fails like above example.

Unfortunately I don't know how to re-open this, so i've cloned it (hopefully
that's the right way)

+++ This bug was initially created as a clone of Bug #1646 +++

Using --inplace with --backup and --backup-dir does not seem to work:

rsync -ax --backup --backup-dir previous destfile remotehost:/destdir/

...or more simply:

rsync -avx --stats --inplace --backup --backup-dir previous \
/etc/hosts /tmp/rsynctest/

strace watching the rsync running on the destination:

write(1, "160134 octets, for a total of 19296646"..., 160134) = 160134
ftruncate64(0x1, 0x1267186, 0, 0, 0x1) = 0
close(1)                    = 0
lstat64(0xbfffebac, 0xbfffba5c) = 0
lstat64(0xbfffa9bc, 0xbfffb9cc) = 0
rename("destfile", "previous/destfile") = 0
lstat64(0x8080780, 0xbfffb9cc) = 0
lstat64(0xbfffebac, 0xbfffba7c) = -1 ENOENT (No such file or directory)
write(4, "i\0\0\10rsync: stat \"/destdir/destfile\" failed: No such file or
directory (2)\n", 109 <unfinished ...>

With --inplace and --backup, shouldn't rsync make the backup file *before*
starting the overwrite?  Then it could (quote) extract the full amount of
network reduction it might otherwise.

I've tried it on two boxes.  Slackware 8.0 (I'm ashamed to admit) glibc2.2, and
Slackware 9.1 glibc 2.3, both kernel 2.6.4, rsync-2.6.3pre1.

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