samba-bugs at samba.org
2011-Sep-14 13:16 UTC
[Bug 8456] New: improve --link-dest bahaviour
https://bugzilla.samba.org/show_bug.cgi?id=8456
Summary: improve --link-dest bahaviour
Product: rsync
Version: 3.0.8
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
Component: core
AssignedTo: wayned at samba.org
ReportedBy: toralf.foerster at gmx.de
QAContact: rsync-qa at samba.org
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
--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
https://bugzilla.samba.org/show_bug.cgi?id=8456
Toralf F?rster <toralf.foerster at gmx.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |DUPLICATE
--- Comment #1 from Toralf F?rster <toralf.foerster at gmx.de> 2011-09-14
13:16:18 UTC ---
*** This bug has been marked as a duplicate of bug 8450 ***
--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
https://bugzilla.samba.org/show_bug.cgi?id=8456
Toralf F?rster <toralf.foerster at gmx.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|DUPLICATE |
--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
https://bugzilla.samba.org/show_bug.cgi?id=8456 --- Comment #2 from Toralf F?rster <toralf.foerster at gmx.de> 2011-09-14 13:17:43 UTC --- *** Bug 8450 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
https://bugzilla.samba.org/show_bug.cgi?id=8456 --- Comment #3 from Kevin Korb <rsync at sanitarium.net> 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). -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
https://bugzilla.samba.org/show_bug.cgi?id=8456 --- Comment #4 from Toralf F?rster <toralf.foerster at gmx.de> 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. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
https://bugzilla.samba.org/show_bug.cgi?id=8456 --- Comment #5 from Kevin Korb <rsync at sanitarium.net> 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). -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
https://bugzilla.samba.org/show_bug.cgi?id=8456 --- Comment #6 from Toralf F?rster <toralf.foerster at gmx.de> 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. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
> In general - --link-dest works as expected *only*, if the destination directory > is empty.Going along with this idea of ensuring the destination directory is empty. LBackup is a rsync backup wrapper system which may be of assistance in this regard. ----------------------------------- This email is protected by LBackup http://www.lbackup.org
https://bugzilla.samba.org/show_bug.cgi?id=8456 --- Comment #7 from Wayne Davison <wayned at samba.org> 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). -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
https://bugzilla.samba.org/show_bug.cgi?id=8456 --- Comment #8 from Toralf F?rster <toralf.foerster at gmx.de> 2013-12-27 13:06:00 UTC --- well - so seems to be solved ? :-) -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Seemingly Similar Threads
- [Bug 8450] New: --link-dest seems not to work mounted NTFS file systems
- [Bug 2269] New: ssh-copy-id: does not respect .ssh/config
- [Bug 3722] New: check ssh key (and other parameters) before running the proxy command
- [Bug 2695] New: inconsistent outout of "ssh.add -l" between ed25519 and rsa keys
- v3.18-rc1 32 bit KVM hangs early in boot process