Re: Hardlink support feasible?

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

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

On Mon, Jan 19, 2026, 3:30=E2=80=AFAM T=C3=B5ivo Leedj=C3=A4rv <toivol@gmai=
l.com> wrote:

> We really need to know what does "syncing hardlinks" even mean. The
> semantics need to be specified in a very detailed way, together with
> the restrictions and constraints.
>
> It is important to keep in mind that the sync is bi-directional and
> path-based. The latter basically means that the current status and
> sync action for each path is decided independently of other paths.
> This already complicates/limits the still-experimental syncing of
> renamed/moved files because that inherently involves two paths in a
> single "action". It will have yet different consequences for
> hardlinking. In a situation where number of links is > 1, the user is
> still able to select a different sync action for each name. As an
> example of why I'm bringing this up, consider the case where n =3D 3.
> The user could select syncing from host A to host B for name 1,
> syncing from host B to host A for name 2, and ignoring the changes
> (skipping the sync) for name 3.
>
> Not knowing your exact need for hardlinks, maybe a different solution
> which is already supported by Unison could work for you? You'd
> possibly have to switch filesystems for /data, but if you can do that
> and you have support from the OS then you could switch to a filesystem
> that supports block-level links (or file clones), also called
> reflinks, which Unison can and will make use of. This way you will be
> spared of copying the synced data twice and data on disk taking up
> space twice. Outside of Unison, instead of cp -l you'd then use cp
> --reflink=3Dalways (with GNU coreutils).
>

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

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

<div dir=3D"auto">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 automatica=
lly. Since the files are never modified except to be reorganized or removed=
 and there&#39;s no real concurrent access, I think my case is considerably=
 simplified.<div dir=3D"auto"><br></div><div dir=3D"auto">Doing the full im=
plementation is probably more than I can bite off right now.</div></div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, J=
an 19, 2026, 3:30=E2=80=AFAM T=C3=B5ivo Leedj=C3=A4rv &lt;<a href=3D"mailto=
:[email protected]" target=3D"_blank" rel=3D"noreferrer">[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);padding-left:1ex">We =
really need to know what does &quot;syncing hardlinks&quot; even mean. The<=
br>
semantics need to be specified in a very detailed way, together with<br>
the restrictions and constraints.<br>
<br>
It is important to keep in mind that the sync is bi-directional and<br>
path-based. The latter basically means that the current status and<br>
sync action for each path is decided independently of other paths.<br>
This already complicates/limits the still-experimental syncing of<br>
renamed/moved files because that inherently involves two paths in a<br>
single &quot;action&quot;. It will have yet different consequences for<br>
hardlinking. In a situation where number of links is &gt; 1, the user is<br=
>
still able to select a different sync action for each name. As an<br>
example of why I&#39;m bringing this up, consider the case where n =3D 3.<b=
r>
The user could select syncing from host A to host B for name 1,<br>
syncing from host B to host A for name 2, and ignoring the changes<br>
(skipping the sync) for name 3.<br>
<br>
Not knowing your exact need for hardlinks, maybe a different solution<br>
which is already supported by Unison could work for you? You&#39;d<br>
possibly have to switch filesystems for /data, but if you can do that<br>
and you have support from the OS then you could switch to a filesystem<br>
that supports block-level links (or file clones), also called<br>
reflinks, which Unison can and will make use of. This way you will be<br>
spared of copying the synced data twice and data on disk taking up<br>
space twice. Outside of Unison, instead of cp -l you&#39;d then use cp<br>
--reflink=3Dalways (with GNU coreutils).<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 />

--000000000000dbe5100648bf4835--