Bug 11866 - rsync fails (failed to re-stat) when using double fuzzy + link-dest on renamed files
rsync fails (failed to re-stat) when using double fuzzy + link-dest on rename...
Status: NEW
Product: rsync
Classification: Unclassified
Component: core
3.1.1
All Linux
: P5 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-04-21 06:54 UTC by Mike Joseph
Modified: 2016-04-21 06:55 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Joseph 2016-04-21 06:54:23 UTC
When using rsync with --fuzzy --fuzzy (double fuzzy) and --link-dest, rsync fails if a file was renamed to a new name on the source that does not exist in the link-dest.  As an example:

mj@backup-server:~/foo$ rm -rf .sync && mkdir .sync && rsync -azSHAXxrsyy --ignore-existing --fake-super --link-dest=/home/mj/foo/current --files-from=:/home/mj/files-to-backup root@backup-client:/ .sync
rsync: failed to re-stat "/home/mj/foo/.sync/etc/motd.old": No such file or directory (2)
rsync: failed to re-stat "/home/mj/foo/.sync/var/log/alternatives.log.1": No such file or directory (2)
rsync: failed to re-stat "/home/mj/foo/.sync/var/log/auth.log.3.gz": No such file or directory (2)
rsync: failed to re-stat "/home/mj/foo/.sync/var/log/daemon.log.3.gz": No such file or directory (2)
rsync: failed to re-stat "/home/mj/foo/.sync/var/log/dpkg.log.1": No such file or directory (2)
rsync: failed to re-stat "/home/mj/foo/.sync/var/log/messages.3.gz": No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1655) [generator=3.1.1]

In each case above, the files which rsync failed to re-stat were ones that existed in the link-dest (/home/mj/foo/current) but under a different name.  For instance:

mj@backup-server:~/foo$ ls -al /home/mj/foo/current/etc/motd*
-rw-r--r-- 7 mj mj 286 Dec 24  2014 /home/mj/foo/current/etc/motd

root@backup-client:/etc# ls -al motd*
-rw-r--r-- 1 root root 314 Apr 21 06:32 motd
-rw-r--r-- 1 root root 286 Apr 21 06:33 motd.bak
-rw-r--r-- 1 root root 286 Dec 24  2014 motd.old

Note that, in this case, rsync didn't fail on motd.bak, just motd.old.  Both contain the same content, but only motd.old has a matching timestamp.

I can completely reproduce this problem on multiple machine pairs and with different file sets.  The problem is resolved by removing the double-fuzzy configuration but, of course, that impairs performance.

All rsync binaries involved are version 3.1.1 (debian 3.1.1-3_amd64).