--recursive and -H
rob at wayne.edu
Sat Jun 26 19:27:38 MDT 2010
Aaah, thanks for the insight. RSYNC must transfer the file regardless of the link count, but it also takes note of the missing link. So, it probably considers an inode with multiple links "resolved" only after it finds a brother/sister link and deletes the duplicate.
This would be consistent w/ the man page:
If incremental recursion is active (see --recursive), rsync may transfer a missing hard-linked file before it finds that another link for that contents exists elsewhere in the hierarchy. This does not affect the accuracy of the transfer, just its efficiency"
Big props to those who code RSYNC, this stuff gets crazy ;)
Rob Thompson, Systems Analyst
Computing & Information Technology
Wayne State University
im: ab5602 at yahoo.com
Public Key: http://pgp.wayne.edu/rob.key
----- "Matthias Schniedermeyer" <ms at citd.de> wrote:
> On 26.06.2010 09:01, Rob Thompson wrote:
> > Hello,
> > I have a question regarding using the --recursive option when
> > preserving hard link with -H. How is it, that these two options are
> > compatible when used together? I would think that RSYNC would need
> > see all files/inodes before transferring, to preserve hard links.
> > yet it still starts transferring before reading the entire file
> That's easy.
> 'stat'ing a file also gives it's inode-number and the link-count
> of directory entries).
> When you have link-count == 1 there is nothing special to do.
> When you have a link-count > 1 you can discard the data as soon as you
> transferred as many files, with the same inode, as the link-count
> Of course the discarding only works as long as all hard-links are
> the directory-subtree you are transfering, otherwise rsync keeps
> up memory, at least i'm pretty sure that rsync works that way.
> Bis denn
> Real Programmers consider "what you see is what you get" to be just as
> bad a concept in Text Editors as it is in women. No, the Real
> wants a "you asked for it, you got it" text editor -- complicated,
> cryptic, powerful, unforgiving, dangerous.
More information about the rsync