Bug 8456 - improve --link-dest bahaviour
improve --link-dest bahaviour
Status: REOPENED
Product: rsync
Classification: Unclassified
Component: core
3.0.8
All All
: P5 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
: 8450 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-14 13:16 UTC by Toralf Förster
Modified: 2013-12-27 13:06 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Toralf Förster 2011-09-14 13:16:05 UTC
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
Comment 1 Toralf Förster 2011-09-14 13:16:18 UTC

*** This bug has been marked as a duplicate of bug 8450 ***
Comment 2 Toralf Förster 2011-09-14 13:17:43 UTC
*** Bug 8450 has been marked as a duplicate of this bug. ***
Comment 3 Kevin Korb 2011-09-14 15:44:28 UTC
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).
Comment 4 Toralf Förster 2011-09-14 16:24:35 UTC
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.
Comment 5 Kevin Korb 2011-09-14 16:28:05 UTC
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).
Comment 6 Toralf Förster 2011-09-14 16:48:16 UTC
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.
Comment 7 Wayne Davison 2013-12-25 23:25:53 UTC
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).
Comment 8 Toralf Förster 2013-12-27 13:06:00 UTC
well - so seems to be solved ? :-)