With rsync --link-dest, if two different source files (not hardlinked
to each other) are both candidates for being hardlinked from files of
the same name in the link-dest directory, both of them may be so
hardlinked. The effect is that on the destination the two files
become hardlined to each other even though they are not hardlinked
together in the source.
I discovered this because my backup system has a stage which checks
that the generated backup directory is truly semantically identical to
the source volume. When --link-dest is used in a backup mechanism the
effect is that if files were previously hardlinks on the source
volume, but something makes them no longer hardlinks by breaking the
link and copying the contents and attributes of the file, this change
is not reflected in the backups.
The bug can be reproduced with the attached shell script.
Run the script, and observe these lines in the output:
1390154 4 -rw-rw-r-- 4 ian ian 9 Mar 27 22:32 ./dst/b
1390154 4 -rw-rw-r-- 4 ian ian 9 Mar 27 22:32 ./dst/a
1390155 4 -rw-rw-r-- 1 ian ian 9 Mar 27 22:32 ./src/b
1390152 4 -rw-rw-r-- 1 ian ian 9 Mar 27 22:32 ./src/a
You can see that the inode numbers of src/a and src/b are different,
whereas the inode numbers of dst/a and dst/b are the same.
rm -rf d
echo contents >src/a
ln src/a src/b
rsync -aH src/. linkdest
cp -a src/a src/b
rsync -aH --link-dest=`pwd`/linkdest/. src/. dst
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com