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


Groups > linux.debian.user > #228909

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

From "Gareth Evans" <donotspam@fastmail.fm>
Newsgroups linux.debian.user
Subject Re: rsync link corruption with -H and --link-dest
Date 2020-11-22 15:40 +0100
Message-ID <BdYH0-1S7-5@gated-at.bofh.it> (permalink)
References <BdTeh-6Yv-7@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Sun, 22 Nov 2020, at 08:44, tomas@tuxteam.de wrote:
> 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
> 
> Attachments:
> * signature.asc

Thanks for your explanation Tomas.

> Please, don't hijack threads

...but what did I do wrong re thread hijacking?

I understand that to mean changing the content of an existing thread, as a quick google seems to confirm.

I did delete the content and change the subject of an existing email, which appears to me to create a new thread, rather than preserving "conversation" links to the deleted content/subject.  

Am I mistaken or did you mean something else?

Thanks,
Gareth

Back to linux.debian.user | Previous | Next — Previous in thread | 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