Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #228904

Re: rsync link corruption with -H and --link-dest

From <tomas@tuxteam.de>
Newsgroups linux.debian.user
Subject Re: rsync link corruption with -H and --link-dest
Date 2020-11-22 09:50 +0100
Message-ID <BdTeh-6Yv-7@gated-at.bofh.it> (permalink)
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

On Sun, Nov 22, 2020 at 04:43:21AM +0000, Gareth Evans wrote:
> Hi all,
> 
> I have asked this question on both the rsync mailing list and serverfault.com but got no response from either.

Please, don't hijack threads.

> I would be grateful, if this isn't too off-topic, if anyone could explain the following:
> 
> man rsync for -H includes:
> 
> "If you specify a --link-dest directory that contains hard links, the linking of the destination files against the --link-dest files can cause some paths in the destination to become linked together due to the --link-dest associations."
> 
> How and/or why does this happen?  What sort of scenario might lead to it?

The way I understand it is this:

Suppose whithin --link-dest, files A and B are hard-linked together.

Now suppose you have two files in your source, say A' and B', with
equal content to A and B (and thus equal themselves, but /not/ linked).
You rsync with --link-dest and with -H. 

Now due to --link-dest, rsync sees "ah, A' == A, so I'll create
A'' on dest hard linked to A'...". Same goes with B and its kin.

Now you end up with two files A'' and B'' on dest which are hard
linked to A' and B' on link-dest which are hard linked together.

Due to how hard links work (they are all just directory entries
pointing all to the same i-node), A'' and B'' are hard linked
together.

Somewhat contradicting your expectation set by -H (preserve hard
links), since the sources A and B had equal content but weren't
hard linked.

This is all, of course, a hunch, and should be backed (or falsified)
by code study and/or experimental evidence, which is left as an
exercise for the reader ;-)

Cheers
 - t

Back to linux.debian.user | Previous | Next — Next in thread | Find similar | Unroll thread


Thread

Re: rsync link corruption with -H and --link-dest <tomas@tuxteam.de> - 2020-11-22 09:50 +0100
  Re: rsync link corruption with -H and --link-dest "Gareth Evans" <donotspam@fastmail.fm> - 2020-11-22 15:40 +0100
    Re: rsync link corruption with -H and --link-dest Celejar <celejar@gmail.com> - 2020-11-22 15:50 +0100
      Re: rsync link corruption with -H and --link-dest "D. R. Evans" <doc.evans@gmail.com> - 2020-11-22 16:20 +0100
    Re: rsync link corruption with -H and --link-dest Andrei POPESCU <andreimpopescu@gmail.com> - 2020-11-22 16:00 +0100
    Re: rsync link corruption with -H and --link-dest tomas@tuxteam.de - 2020-11-22 16:00 +0100
    Hijacking Threads [was: Re: rsync link corruption with -H and  --link-dest] Charles Curley <charlescurley@charlescurley.com> - 2020-11-22 16:10 +0100
      Re: Hijacking Threads [was: Re: rsync link corruption with -H and  --link-dest] Andrei POPESCU <andreimpopescu@gmail.com> - 2020-11-22 16:20 +0100

csiph-web