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

https://bugzilla.samba.org/show_bug.cgi?id=4834

           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@samba.org
        ReportedBy: joost@seat-ibiza.nl
         QAContact: rsync-qa@samba.org


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/
Password:
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.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=4834





------- Comment #1 from hashproduct+rsync@gmail.com  2007-09-22 21:47 CST
-------
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.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=4834


wayned@samba.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Comment #2 from wayned@samba.org  2007-09-23 16:10 CST -------
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!


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.