The Samba-Bugzilla – Bug 4834
--inplace with --backup --backup-dir does not work
Last modified: 2007-09-23 16:10:19 UTC
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@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) [sender=2.6.9]
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 \
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.
I can reproduce the behavior Joost described. It gets much worse: in whole-file mode, rsync updates the destination file without even attempting to back it up. This is because the "if (... || whole_file) goto notify_others;" that skips over the code that does backups when --inplace is on.
The --inplace code now properly calls a directory-making function when necessary to be able to create the backup file.
When --inplace is combined with --whole-file and/or --read-batch, the backup is no longer (accidentally) skipped.