Bug 4834 - --inplace with --backup --backup-dir does not work
--inplace with --backup --backup-dir does not work
Product: rsync
Classification: Unclassified
Component: core
All Linux
: P3 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
Depends on:
  Show dependency treegraph
Reported: 2007-07-30 06:29 UTC by Joost van den Broek
Modified: 2007-09-23 16:10 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Joost van den Broek 2007-07-30 06:29:22 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 \
/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.
Comment 1 Matt McCutchen 2007-09-22 21:47:24 UTC
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.
Comment 2 Wayne Davison 2007-09-23 16:10:19 UTC
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.

Thanks, guys!