rsync - Aug 2005 - [Bug 2947] stdout with [-v] -H --link-dest and slink/sock/fifo/regf

https://bugzilla.samba.org/show_bug.cgi?id=2947


wayned@samba.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




------- Additional Comments From wayned@samba.org  2005-08-03 16:45 -------
Keep in mind that --link-dest only hard-links regular files, and nothing else
(and I want to keep it that way, since not all systems can hard-link things such
as symlinks, and there's not that much of a savings in hard-linking devices
and
symlinks anyway).  Also, while rsync's output treats files that are already
up-to-date in a link-dest dir just like they were up-to-date in the destination
dir (i.e. it doesn't output their names as transferred files without an
extra
-v), rsync does not currently consider the contents of the link-dest dirs when
it is deleting (though that might be interesting to do so, it could get very
complicated when using multiple --link-dest options).

So, the only thing that I see that I'd consider improving is the output of a
hard-linked file that had an up-to-date counterpart in the link-dest dir and a
linked-"buddy" in the current destination hierarchy -- in that case
rsync
outputs that it is hard-linking the latter files into cluster to the first file
of the cluster, when it should arguably be silent about that file.

-- 
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.

https://bugzilla.samba.org/show_bug.cgi?id=2947





------- Additional Comments From noreply@cpe-24-95-90-2.columbus.res.rr.com 
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.