https://bugzilla.samba.org/show_bug.cgi?id=2947
------- Additional Comments From [EMAIL PROTECTED] 2005-08-03 23:36 -------
>link-dest only hard-links regular files...savings in hard-linking [non-regular
files]
yeah, they all take the same directory space, any savings would be in inode
count.
>multiple --link-dest options
never used this, can someone using this post a useful context?
isn't this just an OR of reference hiers that result in a final same/notsame
decision to print/do? if it's hard to code maybe caveat support to just one
link-dest option?
hmm, maybe put another way... it would be nice to be able to run
rsync -nHaxv --delete --link-dest=`pwd`/1/ ./0/ ./2/
and see only what the changes would be. then run without -n and have it print
and do exactly the same. right now it says [by printing output] that, hey, i'm
going to make a bunch of new slink/socket/fifo/device and hardlinks of same/regf
in ./2/ [as if they were newly created in ./0/ post when ./1/ was created
earlier,
even though that is false]...and by the way, i might tell you about that
new/modified regfile that showed up in ./0/ [post ./1/], but i'm not going to
warn/tell you that file disappeared. that behaviour seems wrong...er, point is
to
accurately say what will be and is done between src and dst, with or without
the link-dest reference. create/mtime_change/delete should be what's printed
with one -v regardless of S_IFMT type. as is done today with
rsync -Haxv --delete ./src/ ./dst/
where the src contains only regular files and dirs with no hardlinks. the
nothing
but errors without -v is great idea.
is this more helpful to anyone?
example:
ls -liRT
240876 drwxr-xr-x 2 tooba wheel 512 Aug 3 22:04:30 2005 0
./0:
240865 -rw-r--r-- 1 tooba wheel 0 Aug 3 22:04:23 2005 a
240855 -rw-r--r-- 2 tooba wheel 0 Aug 3 21:51:56 2005 h1
240855 -rw-r--r-- 2 tooba wheel 0 Aug 3 21:51:56 2005 h2
rsync -Haxv --delete ./0/ ./1/ <-- make first copy, lev0
created directory ./1
./
a <-- ok
h2 <-- ok
h1 => h2 <-- ok
240876 drwxr-xr-x 2 tooba wheel 512 Aug 3 22:04:30 2005 0
240850 drwxr-xr-x 2 tooba wheel 512 Aug 3 22:04:30 2005 1
./0:
240865 -rw-r--r-- 1 tooba wheel 0 Aug 3 22:04:23 2005 a
240855 -rw-r--r-- 2 tooba wheel 0 Aug 3 21:51:56 2005 h1
240855 -rw-r--r-- 2 tooba wheel 0 Aug 3 21:51:56 2005 h2
./1:
240856 -rw-r--r-- 1 tooba wheel 0 Aug 3 22:04:23 2005 a
240857 -rw-r--r-- 2 tooba wheel 0 Aug 3 21:51:56 2005 h1
240857 -rw-r--r-- 2 tooba wheel 0 Aug 3 21:51:56 2005 h2
rsync -Haxv --delete --link-dest=`pwd`/1/ ./0/ ./2/ <-- first referential copy
lev1
created directory ./2
./ <-- ignoring these at the moment, not as important
h2 => h1 <-- no need to know, this is not a difference between 0 and 2
rm 0/a <-- now nuke this
rsync -Haxv --delete --link-dest=`pwd`/2/ ./0/ ./3/
created directory ./3
./
h2 => h1 <-- no need to know, this is not a difference between 0 and 2
<-- but hey, where'd my informative 0/a deletion printf go...
touch 0/b <-- now create this
rsync -Haxv --delete --link-dest=`pwd`/3/ ./0/ ./4/
created directory ./4
./
b <-- ... because i correctly tell you of create/update_mtime here
h2 => h1 <-- no need to know, this is not a difference between 0 and 2
rm 0/h1 <-- now nuke this
rsync -Haxv --delete --link-dest=`pwd`/4/ ./0/ ./5/
created directory ./5
./
<-- but hey, where'd my informative 0/h1 deletion printf go...
ln 0/h2 0/h3 <-- now create this
rsync -Haxv --delete --link-dest=`pwd`/5/ ./0/ ./6/
created directory ./6
./
h3 => h2 <-- ok, this is a true difference
if using the usual full test srcdir as ./0/, i get...
240903 lrw-rw---- 1 tooba wheel 1 Aug 2 00:47:11 2005 a -> b
240912 -rw-rw---- 1 tooba wheel 0 Jul 31 22:39:05 2005 b
240904 prw-rw---- 1 tooba wheel 0 Aug 4 02:03:22 2005 fifo0
240905 prw-rw---- 2 tooba wheel 0 Aug 2 00:47:06 2005 fifohard1
240905 prw-rw---- 2 tooba wheel 0 Aug 2 00:47:06 2005 fifohard2
240878 -rw-rw---- 1 tooba wheel 0 Aug 4 02:03:22 2005 file0
240914 -rw-rw---- 2 tooba wheel 0 Jul 31 22:58:45 2005 filehard1
240914 -rw-rw---- 2 tooba wheel 0 Jul 31 22:58:45 2005 filehard2
240906 brw-rw---- 1 tooba wheel 2, 2 Aug 4 02:03:22 2005 nullb0
240907 brw-rw---- 2 tooba wheel 2, 2 Aug 4 01:48:48 2005 nullbhard1
240907 brw-rw---- 2 tooba wheel 2, 2 Aug 4 01:48:48 2005 nullbhard2
240908 crw-rw---- 1 tooba wheel 2, 2 Aug 4 02:03:22 2005 nullc0
240909 crw-rw---- 2 tooba wheel 2, 2 Aug 4 01:50:01 2005 nullchard1
240909 crw-rw---- 2 tooba wheel 2, 2 Aug 4 01:50:01 2005 nullchard2
240910 srw-rw---- 1 tooba wheel 0 Aug 4 02:03:22 2005 socket0
240911 srw-rw---- 2 tooba wheel 0 Aug 4 02:05:00 2005 sockethard1
240911 srw-rw---- 2 tooba wheel 0 Aug 4 02:05:00 2005 sockethard2
rsync -Hax --delete ./0/ ./1/
rsync -Haxvi --delete --link-dest=`pwd`/1/ ./0/ ./2/
created directory ./2
.d..t.o.. ./
cL+++++++ a -> b
cD+++++++ fifo0
cD+++++++ fifohard2
hD+++++++ fifohard1 => fifohard2
hf+++++++ filehard2 => filehard1 <-- note reversal of 1 => 2 number
cD+++++++ nullb0 order compared to first copy wayyy
cD+++++++ nullbhard2 up ^^^^ there ;-]
hD+++++++ nullbhard1 => nullbhard2
cD+++++++ nullc0
cD+++++++ nullchard2
hD+++++++ nullchard1 => nullchard2
cD+++++++ socket0
cD+++++++ sockethard2
hD+++++++ sockethard1 => sockethard2
none of which have actually changed.
for the reader...
-H used here as a standard addition to -a, for more identical mirroring.
with that, df -i also happens to match up between mirrors as an added quick
check.
the -H preserves the link relationships that exist between names in ./0/
through to the mirror in ./2/. link-dest just saves space between ./1/
and ./2/. with millions of files, each consuming more than their directory
space,
link-dest is just plain cool;-]
sockets/[bc]devices/fifos consume zero bytes, slinks/dirs some bytes. and
regulars
use a lot in comparison.
being careful discussing 'devices' is important as block and char devices are
different from each other and from sockets, symlinks and fifos which are all
independant types and NOT devices proper. see stat(2).
imo, rsync has done an excellent job of becoming aware of the seven common file
types in the past year or two with just a little more to go. ie: log-format,
a type section in the man page, this series of hopefully useful reports.
hats off to the coders.
--
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.
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
