[Unison-hackers] move instead of copy

[Benjamin C. Pierce]

> One could also fix the problem by copying with something like 'cp
> --reflink', right? Perhaps that would also be useful.

Yes, that would be a simple alternative on a filesystem that supports reflinks.

> P.S. I thought Unison used O'Caml not Erlang…

Yes.

   - B


> 
> On Mon, Sep 14, 2015 at 11:20:08AM -0400, Benjamin C. Pierce wrote:
>> I agree this would be a useful feature.  
>> 
>> It may not be completely trivial to implement — in general, the file transfer code is somewhat complex — but if you want to take a look, I think the right place to add this functionality would be as a special case in the doAction function in the module transport.ml: before calling Copy.copy to do the file copy, you’d check whether the copy is local and the source of the copy (i.e., the file at the old location) is scheduled to be deleted (because the file was actually moved), and if so implement the copy as a move.  (The last check — whether the file is scheduled to be deleted — is needed because Unison’s model of filesystems doesn’t actually recognize moves as such: a move will be recognized as a create and a delete, and the user might well allow the create to proceed but cancel the delete in the user interface, in which case Unison should really perform a copy.  Changing the fundamental model to recognize moves as such would be a bigger job, involving UI changes for example.)
>> 
>>    - Benjamin
>> 
>> 
>>> On Sep 12, 2015, at 6:53 AM, Hadmut Danisch <hadmut at danisch.de> 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
>>> 
>>> _______________________________________________
>>> Unison-hackers mailing list
>>> Unison-hackers at lists.seas.upenn.edu
>>> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
>> 
>> _______________________________________________
>> Unison-hackers mailing list
>> Unison-hackers at lists.seas.upenn.edu
>> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers