[Unison-hackers] move instead of copy

[Mario Emmenlauer]

Dear Hadmut,

+1 from me for this request!


On 12.09.2015 12:53, Hadmut Danisch wrote:
> 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



Viele Gruesse,

    Mario


--
BioDataAnalysis GmbH, Mario Emmenlauer       Mobil: +49-(0)151-68108489
Balanstrasse 43                mailto: memmenlauer * biodataanalysis.de
D-81669 München                          http://www.biodataanalysis.de/