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.
Yes, this combination of options did not work at all right (rsync updated the
file inplace and then moved the file into the backup dir -- ouch!).
I've checked in a file that has the generator copy a backup during the checksum
generation phase when --inplace was specified with --backup. Then, the code was
further improved to use the backup file as the basis file so that the normal
--inplace limits on skipping overwritten blocks was not needed. This, as you
noted, makes the transfer as efficient as if --inplace was not used.