[Unison-hackers] move instead of copy

Hadmut Danisch hadmut at danisch.de
Sat Sep 12 06:53:27 EDT 2015


Hi,

I'm aware that unison is not fully supported anymore, but I'd like to
ask to add a little feature. I tried to patch it myself, but although
familiar with >20 programming languages, I'm not familiar at all with
erlang and did not even find in the source codes where those things were
happening I am looking for.

I'm using unison for years and was always happy with it, but since I am
using new filesystems with snapshots, such as btrfs and zfs, unison
causes some trouble.


If there is a file, synchronized on two machines, and it is moved to a
different location (or simply renamed) on one machine, then unison does
copy that file on the new machine and then delete the old one. Although
unison recognizes, that it does not need to transmit the file over the
network, because it already has such a file on the target machine, it
creates a new file and deletes the old one.

This is a problem if there is an older snapshot in the filesystem,
because if you move a file, it does not occupy new disk space, while it
does when copied. Since the old file is still contained in the snapshot,
the disk space is not released. While the occupied disk space remains
constand on the first system, it doubles at the target system.

So unison is somewhat incompatible with filesystems supporting snapshots.

It should not be too difficult to implement a move instead of copy and
delete, since unison already knows what it needs to know: It detects
that the new file is a copy of a file already existent at the target
machine and thus does not need to be transmitted. And it detects that
the old file is not needed anymore and can be deleted.

Would be quite important to convert this copy+delete into a rename in
order to support new file systems, since especially for storage these
file systems are used (e.g. because of checksums, raid, etc.).

Would be much easier to implement for someone familiar with erlang and
unison, than for me.

regards
Hadmut



More information about the Unison-hackers mailing list