Considering the following sequence I'd expect after the last command that the file /tmp/rsync_test/c/rand1M would have the inode number 909377 - instead it is a new copy of an unchanged file :-( $ rm -rf /tmp/rsync_test/ $ mkdir -p /tmp/rsync_test/{a,b,c} $ dd if=/dev/urandom of=/tmp/rsync_test/a/rand1M bs=1024 count=1024 2>/dev/null $ rsync --archive --itemize-changes /tmp/rsync_test/a/ /tmp/rsync_test/b .d..t...... ./ >f+++++++++ rand1M $ touch /tmp/rsync_test/c/rand1M $ rsync --archive --itemize-changes /tmp/rsync_test/a/ /tmp/rsync_test/c --link-dest=/tmp/rsync_test/b .d..t...... ./ >f.st...... rand1M $ ls -il /tmp/rsync_test/?/* 909361 -rw-r--r-- 1 tfoerste users 1048576 Sep 14 15:12 /tmp/rsync_test/a/rand1M 909370 -rw-r--r-- 1 tfoerste users 1048576 Sep 14 15:12 /tmp/rsync_test/b/rand1M 909377 -rw-r--r-- 1 tfoerste users 1048576 Sep 14 15:12 /tmp/rsync_test/c/rand1M
*** This bug has been marked as a duplicate of bug 8450 ***
*** Bug 8450 has been marked as a duplicate of this bug. ***
The simple fact is that two links to the same inode are not 2 different files but the same file. Their attributes by definition are the same. They cannot have different time stamps. If you tell rsync to synchronize time stamps then it will update the time stamp in the target. It cannot do that and maintain the time stamp in the link-dest (which is read only as far as rsync is concerned) at the same time. This is simply impossible. Note that if you do not synchronize timestamps the result would be pretty much the same as --ignore-times which would probably be a bigger problem for you. The only thing rsync could possibly do would be to add an option to allow for minor changes to affect the files within the link-dest (and probably other previously used link-dests).
No, the problem is a complete different IMHO: If the "touch" command is skipped, then rsync does hard-link the file instead to copy it over ! In general - --link-dest works as expected *only*, if the destination directory is empty.
Oops, I read what I thought you were saying instead of what you were. That behavior is documented in the man page: This option works best when copying into an empty destination hierarchy, as rsync treats existing files as definitive (so it never looks in the link-dest dirs when a destination file already exists), and as malleable (so it might change the attributes of a destination file, which affects all the hard-linked versions).
well - now the Oops is on my side ;-) - really overlooked that part of the man page. Is there any chance to convince rsync to always look into --link-dest ? background : I'd like to use rsync as an efficient (== do not store the same file twice at the backup media) backup solution. The backup should be made into N remote directories (rotating each day) _without_ the need to delete the remote directory before.
The latest rsync will now look into link-dest dirs even for files that exist in the destination directory hierarchy. It still requires all preserved attributes to match for the link to occur, though (e.g. if preserving --times, the mtime must match). What it doesn't yet support is an option to tell rsync to not modify attributes on any hard-linked file in the dest hierarchy (they still get their attrs tweaked in-place).
well - so seems to be solved ? :-)