DO NOT REPLY [Bug 3693] rsync can use same --link-dest file several
times, leading to incorrect hard links
samba-bugs at samba.org
samba-bugs at samba.org
Mon Apr 17 19:15:48 GMT 2006
https://bugzilla.samba.org/show_bug.cgi?id=3693
------- Comment #1 from noreply at cpe-24-95-90-2.columbus.res.rr.com 2006-04-17 14:15 MST -------
> ...
> The source files src/f1 and src/f2 are both identical to the single
> link-dest file that has the names linkdest/f1 and linkdest/f2.
the contents are the same but some of the meta information is not.
> Rsync links linkdest/f1 instead of copying src/f1 and links linkdest/f2
> instead of copying src/f2. Now dest/f1 and dest/f2 refer to the same
> file while src/f1 and src/f2 refer to different files.
can you post the output inline with commands as i'm not seeing this here...
[] ls -aliT .
[] <nothing>
[] sleep 2 ; mkdir src
[] sleep 2 ; mkdir dest
[] sleep 2 ; mkdir linkdest
[] sleep 2 ; touch src/f1
[] sleep 2 ; rsync -a src/f1 src/f2
[] sleep 2 ; touch linkdest/f1
[] sleep 2 ; ln linkdest/f1 linkdest/f2
[] ls -aliT *
dest:
<nothing>
linkdest:
238252 -rw-r--r-- 2 moo moo 0 Apr 17 14:12:30 2006 f1
238252 -rw-r--r-- 2 moo moo 0 Apr 17 14:12:30 2006 f2
src:
238250 -rw-r--r-- 1 moo moo 0 Apr 17 14:12:26 2006 f1
238251 -rw-r--r-- 1 moo moo 0 Apr 17 14:12:26 2006 f2
# i modified the erroneous[?] link-dest usage of both a relative and a
# nonexistant path. in the past i had problems with relative. should
# rsync complain about nonexistance with -v?
[] sleep 2 ; rsync -Hav src/ dest/ --link-dest=`pwd`/linkdest/
./
f1
f2
[] ls -aliT *
dest:
238287 -rw-r--r-- 1 moo moo 0 Apr 17 14:12:26 2006 f1
238288 -rw-r--r-- 1 moo moo 0 Apr 17 14:12:26 2006 f2
linkdest:
238252 -rw-r--r-- 2 moo moo 0 Apr 17 14:12:30 2006 f1
238252 -rw-r--r-- 2 moo moo 0 Apr 17 14:12:30 2006 f2
src:
238250 -rw-r--r-- 1 moo moo 0 Apr 17 14:12:26 2006 f1
238251 -rw-r--r-- 1 moo moo 0 Apr 17 14:12:26 2006 f2
> I believe that, when -H is specified, two destination dentries should refer
> to the same file if and only if the corresponding source dentries do
true, but not the same inode number across src and dest. only within src. and
only within dest. 'same file' means 'same inode number'. there are cross host
and cross filesystem aspects as well. besides, src and dest must be different
inode sets, otherwise munging a source file would also munge your backup ;-]
in your example, at least as reproduced above, src/{f1,f2} are not hardlinks.
so rsync has no obligation to, and indeed should not, make dest/{f1,f2}
hardlinks. with or without -H. if src/{f1,f2} were hardlinks, with -H would
preserve that relationship in dest. without -H would just make copies.
remember, a --link-dest directory is only used as a reference to save
space/time in the destination. the dest must always mirror the src regardless
of what's in any chosen --link-dest dir. in your example, linkdest/{f1,f2}
could be thought of as a previous mirror of the src that _did_ have
src/{f1,f2} hardlinked, before something came along and broke them up in the
src. thus now the new dest has them correctly separated.
> <remainder of report>
not sure how to read that. though i think the current behaviour is correct.
as an aside, any change to:
name, perm, uid, gid, size, contents, mtime, existance,
symlink '-> source' or hardlink relationship
will/should cause the -Ha --link-dest --delete version to be ignored and a
new copy to be made in dest. there is both mtime and hardlink change in the
example.
--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
More information about the rsync
mailing list