Re: Hardlink support feasible?

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 = 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=always (with GNU coreutils).

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