WayneD
commented
3 years ago I would expect all three runs to transfer all files to the destination directory.
That is not a valid expectation given that only some of the runs use --compare-dest, whose purpose is to elide files from the destination that are already present in the alt-dest directory (the option creates a sparse tree of just the modified/added files).
What looks to be going on is that rsync finds that the 2nd file is already in the compare dir, so rsync marks it as finished and skips it. However, its source file is hard-linked to another later file in the transfer, so rsync throws an error when that later file's transfer can't find the omitted file in the "lingering" list of files that need to be hard-linked together. Rsync's confusion stems from the fact that nothing marked the hard-link group as finished yet, and the 2nd file is listed as last in a group of 2 files (so it expects there to be an earlier file that need to be hard-linked with this new file) and rsync only keeps around data for unfinished files (to save memory). It is strange that the run 1 part 2 does not run into the same problem, but then I figured out that when the file doesn't need to be transferred, there hasn't been enough time for the generator to throw away the earlier file-list data yet, so it finds the linked file and notices that it is already flagged as finished and leaves it alone.
There are a couple ways this could be fixed. The easiest is to make rsync refuse to allow --hard-links when --compare-dest is used, since it's a weird use case to want hard-linking when creating a sparse tree of changed files. The other solution would be to figure out how to affect the flags to remove an elided file from the list of hard-linked files, which can shorten a hard-link group. I believe that there is some code that already elides an error-generating file from the hard-linked list, so the latter fix may not be too bad. I can give it a look soon.
My compliments on the wonderful bug report and such a thorough abundance of information. Let me know if you disagree with my conclusions.
cr1901
eharris
I have created a minimized tree of files, with one duplicate hard link, that causes
rsyncto error out with a crypticFile-list index 24 not in 31 - 32 (finish_hard_link) [generator] rsync error: protocol incompatibility (code 2) at rsync.c(740) [generator=3.1.1]: duplicate.tar.gz.I created this tree after getting this error while examining previous backups using rsync with the
compare-destargument.Duplicating the Error
To duplicate, untar, and run the supplied
build-error.sh. I have gotten this error on multiple machines and multiple rsync versions, including the HEAD of master earlier today:Run 1
Run 1, Part 2
If
./build-error.shimmediately run a second time after the above error, the second run ofrsyncsucceeds:However, only one copy of
7bf52a3b7e19db9d1f63fe6366d0abbac678d60e.idxgets to the destination directory:Things That Hide The Error
Run 2
If
pack-524f05f69ee946cb582d7f4d988964b2015b63e6.idxis deleted from the tree, thersyncinvocation returns no error without modification. However, only one file is sent!:Run 3
If the
--compare-destargument is removed from./build-error.sh, thersyncinvocation succeeds, with the same file size as in the above Run 1, Part 2 section, but with different files sent compared to the above!:Expected Behavior
I am not sure where to even begin diagnosing the behavior I'm seeing here. Depending on how I run
rsync,rsyncwill have divergent behavior when I don't expect it to. Based on the three (I'm counting "running the script twice" as one way) ways I'm running this script on this tree, I would expect all three runs to transfer all files to the destination directory. Actual behavior may causersyncto error out withprotocol incompatibility (code 2)and/or not transfer all files.Description of the Tar File
The
duplicatetree has "5" files including the supplied script. This was the best I could do after several hours to minimize a repeatable test case. Two of the "three"7bf52a3b7e19db9d1f63fe6366d0abbac678d60e.idxfiles have the same inode.The contents of all "three" copies of
7bf52a3b7e19db9d1f63fe6366d0abbac678d60e.idxare identical: