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

Groups > linux.debian.user > #228904 > unrolled thread

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

Back to article view | Back to linux.debian.user

Contents

  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

#228904 — Re: rsync link corruption with -H and --link-dest

[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

[toc] | [next] | [standalone]

#228909

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

[toc] | [prev] | [next] | [standalone]

#228910

On Sun, 22 Nov 2020 14:36:06 +0000
"Gareth Evans" <donotspam@fastmail.fm> wrote:

> On Sun, 22 Nov 2020, at 08:44, tomas@tuxteam.de wrote:

...

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

In "proper" email systems, threading is determined by Message-ID,
References, and In-Reply-To headers, not the subject line and content:

https://cr.yp.to/immhf/thread.html

Non-"proper" emails systems, such as, IIRC, Gmail, may do threading
based on subject and content ;)

On a list like this, changing the subject line while leaving the other
headers in place will result in many users' MUAs still associating the
new message with the old thread, annoying those users. Just compose a
new message.

Celejar

[toc] | [prev] | [next] | [standalone]

#228915

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

Celejar wrote on 11/22/20 7:46 AM:

> On a list like this, changing the subject line while leaving the other
> headers in place will result in many users' MUAs still associating the
> new message with the old thread, annoying those users. Just compose a

And also meaning that users such as myself who weren't following the original 
thread never even saw your question at all. So it's in your own interest to 
thread messages properly, because otherwise some people who might want to 
respond to your issue, or otherwise be interested in it, might not ever see 
the issue raised if you don't start a new thread.

   Doc

-- 
Web:  http://enginehousebooks.com/drevans

[toc] | [prev] | [next] | [standalone]

#228911

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

On Du, 22 nov 20, 14:36:06, Gareth Evans wrote:
> On Sun, 22 Nov 2020, at 08:44, tomas@tuxteam.de wrote:
> 
> > 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?

Threading is done based on more information than just the Subject. With 
most e-mail clients changing the Subject will still keep that 
information (on purpose, there may be good reasons for the author to do 
that).

At https://lists.debian.org/debian-user/2020/11/threads.html you can see 
for yourself how your message is linked to the "files in zoneinfo" 
thread. It's the same for everybody reading the list on a 
thread-aware[1] e-mail client.

[1] as in e-mail clients that properly read (and set) the threading 
headers (In-Reply-To and References).

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#228912

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

On Sun, Nov 22, 2020 at 02:36:06PM +0000, Gareth Evans wrote:
> On Sun, 22 Nov 2020, at 08:44, tomas@tuxteam.de wrote:

[mumble mumble]

> Thanks for your explanation Tomas.

You are welcome. But bear in mind that this is yet a hunch, not
backed by evidence, so use with care :)

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

Don't take that personally. Just as a reminder to us all. I do fall
into this trap from time to time, too.

In your case, you did edit the subject -- but you left the message
references intact. Quoting from your headers:

  In-Reply-To: <20201122042154.GU7548@bitfolk.com>
  References: <1182213078.73974.1605925808686.ref@mail.yahoo.com>
          <1182213078.73974.1605925808686@mail.yahoo.com>
          <20201121085613.GA12787@tuxteam.de> <E1kgYR5-0004Cq-4S@wb5agz>
          <20201121213621.GN7548@bitfolk.com> <E1kgfQq-0006Ay-0j@wb5agz>
          <20201122042154.GU7548@bitfolk.com>

Especially the header In-Reply-To is used by MUAs (and archive software)
to link mails together. In this case, it refers to a mail by Andy Smith
with the subject "780 files in /usr/share/zoneinfo/".

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#228914 — Hijacking Threads [was: Re: rsync link corruption with -H and --link-dest]

On Sun, 22 Nov 2020 14:36:06 +0000
"Gareth Evans" <donotspam@fastmail.fm> wrote:

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

Correct.

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

Yes. Which is how one usually hijacks a thread.

The problem is that among the headers in emails is one that provides an
identifier for the thread. So properly written mail user agents (MUA,
your email client) will put the freshly hijacked message right into the
thread anyway.

Why this is wrong:

* It interrupts the flow of the thread by interpolating a completely
  new subject in the middle of an existing thread.

* It makes it harder for searchers later on to find your subject, hence
  to find any solution to your problem.

* Starting a new email is usually easier than hijacking a thread, so
  why bother?



-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#228916 — Re: Hijacking Threads [was: Re: rsync link corruption with -H and --link-dest]

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

On Du, 22 nov 20, 08:01:16, Charles Curley wrote:
> 
> * Starting a new email is usually easier than hijacking a thread, so
>   why bother?

Starting a new e-mail requires filling out at least the To: address so 
it is easier to reply instead (especially with many addresses in To: and 
Cc: that one wants to keep).

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web