Re: Hardlink support feasible?

--00000000000045a91c0648c47749
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I haven't followed the details of this exchange, but just a historical note
that the reason Unison doesn't have hardlink support is that we never
succeeded in understanding what it would mean!  That's not to say that it's
impossible to understand, of course -- rather, consider it as a bid for
starting with a very simple, abstract model (e.g., the one here
<https://urldefense.com/v3/__https://www.researchgate.net/publication/25761=
01_What_is_a_File_Synchronizer__;!!IBzWLUs!R4dmyPiUz7T8d9SlAy4dHAeKEkGzK81h=
Ca3a1RyfTtlfH8jvCuOTKg71Dy3tCpVqgfpNVR2e8wuCRadWfSjfJk6kexcejA$ >)
and trying to extend it.

     - Benjamin

On Mon, Jan 19, 2026 at 1:43=E2=80=AFPM Greg Troxel <[email protected]> wrote:

> Alan Savage <[email protected]> writes:
>
> > What I do now is `rsync -H` between the two machines and when I need
> > something deleted or moved, I run the command on both machines. I was
> > hoping Unison would sync changes to the other side for me automatically=
.
> > Since the files are never modified except to be reorganized or removed
> and
> > there's no real concurrent access, I think my case is considerably
> > simplified.
> >
> > Doing the full implementation is probably more than I can bite off righ=
t
> > now.
>
> If you'd like to try to write the behavior specification, that would
> still be interesting by itself.
>
> It would be possible to say that when an action is chosen for one member
> of a hardlink set, it's applied to all, but I'm not at all sure we want
> to cross that bridge.  It's even harder to think about if the hardlink
> state is inconsistent, and how the user chooses to get consistent.
>
>
> Overall this seems more difficult than the human effort that is likely
> willing to be applied.  I don't want to ask you to do something you will
> not end up feeling was worthwhile, so it seemed fairer to express that
> thought.
>
> You might want to first make a program, not part of unison, that goes
> over a directory tree and turns a set of files that are the same (and
> not zero-length) into hardlinks.
>
> A more limited change to unison might be "if both sides are hardlink
> sets and are the same, call that a match", or slide the previous archive
> state into the hardlinked state, if it doesn't already.  That might get
> a lot of the practical benefit and might provide some insight.
>
>
>

To unsubscribe from this group and stop receiving emails from it, send an e=
mail to [email protected].

--00000000000045a91c0648c47749
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I haven&#39;t followed the details of this exchange, but j=
ust a historical note that the reason=C2=A0Unison doesn&#39;t have hardlink=
 support=C2=A0is that we never succeeded in understanding what it would mea=
n!=C2=A0 That&#39;s not to say that it&#39;s impossible to understand, of c=
ourse -- rather, consider it as a bid for starting with a very simple, abst=
ract model (e.g., the one <a href=3D"https://urldefense.com/v3/__https://ww=
w.researchgate.net/publication/2576101_What_is_a_File_Synchronizer__;!!IBzW=
LUs!R4dmyPiUz7T8d9SlAy4dHAeKEkGzK81hCa3a1RyfTtlfH8jvCuOTKg71Dy3tCpVqgfpNVR2=
e8wuCRadWfSjfJk6kexcejA$">here</a>) and trying to extend it.<div><br></div>=
<div>=C2=A0 =C2=A0 =C2=A0- Benjamin</div></div><br><div class=3D"gmail_quot=
e gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jan =
19, 2026 at 1:43=E2=80=AFPM Greg Troxel &lt;<a href=3D"mailto:[email protected]=
m">[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">Alan Savage &lt;<a href=3D"mailto:[email protected]" tar=
get=3D"_blank">[email protected]</a>&gt; writes:<br>
<br>
&gt; What I do now is `rsync -H` between the two machines and when I need<b=
r>
&gt; something deleted or moved, I run the command on both machines. I was<=
br>
&gt; hoping Unison would sync changes to the other side for me automaticall=
y.<br>
&gt; Since the files are never modified except to be reorganized or removed=
 and<br>
&gt; there&#39;s no real concurrent access, I think my case is considerably=
<br>
&gt; simplified.<br>
&gt;<br>
&gt; Doing the full implementation is probably more than I can bite off rig=
ht<br>
&gt; now.<br>
<br>
If you&#39;d like to try to write the behavior specification, that would<br=
>
still be interesting by itself.<br>
<br>
It would be possible to say that when an action is chosen for one member<br=
>
of a hardlink set, it&#39;s applied to all, but I&#39;m not at all sure we =
want<br>
to cross that bridge.=C2=A0 It&#39;s even harder to think about if the hard=
link<br>
state is inconsistent, and how the user chooses to get consistent.<br>
<br>
<br>
Overall this seems more difficult than the human effort that is likely<br>
willing to be applied.=C2=A0 I don&#39;t want to ask you to do something yo=
u will<br>
not end up feeling was worthwhile, so it seemed fairer to express that<br>
thought.<br>
<br>
You might want to first make a program, not part of unison, that goes<br>
over a directory tree and turns a set of files that are the same (and<br>
not zero-length) into hardlinks.<br>
<br>
A more limited change to unison might be &quot;if both sides are hardlink<b=
r>
sets and are the same, call that a match&quot;, or slide the previous archi=
ve<br>
state into the hardlinked state, if it doesn&#39;t already.=C2=A0 That migh=
t get<br>
a lot of the practical benefit and might provide some insight.<br>
<br>
<br>
</blockquote></div>

<p></p>

To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:[email protected]">unison-u=
[email protected]</a>.<br />

--00000000000045a91c0648c47749--