[Unison-hackers] Upgrade the unison stable version

[Sylvain Le Gall]

Hello,

On 12-12-2006, Benjamin Pierce <bcpierce at cis.upenn.edu> wrote:
> I have implemented the fix we discussed.  A new version will be  
> committed shortly.
>
>     - Benjamin
>
>

Debian etch has froze yesterday: too late :-(

Anyway, i think it is good to have this in unison... Thanks a lot.

Thanks a lot for your work on unison

Kind regard
Sylvain Le Gall

> On Oct 7, 2006, at 3:58 AM, Sylvain Le Gall wrote:
>
>> Hello,
>>
>> On 06-10-2006, Benjamin Pierce <bcpierce at cis.upenn.edu> wrote:
>>>>>> Do you have an idea for a quick fix, for the 2.13.16 version ?
>>>>>
>>>>> Yes: Document the fact that Unison is not safe to use with  
>>>>> removable
>>>>> media.
>>>>>
>>>>
>>>> Well, i could do that, but it is not really fair regarding the  
>>>> bug...
>>>
>>> I don't understand why you say that.  Unison is behaving exactly as
>>> it is designed to behave and exactly as its documentation specifies.
>>> The issue here is that, when a piece of removable storage goes
>>> offline, the filesystem will tell Unison that all the files on it are
>>> gone, and Unison will *correctly* (though, I agree, surprisingly)
>>> delete all of them from the other replica.
>>>
>>
>> Indeed, you are right, i am not saying that anything is wrong  
>> regarding
>> unison, i just try to say that it won't really solve the problem (even
>> if the problem is a correct behavior).
>>
>>>> If it is a question of time for working on the issue, i think i  
>>>> don't
>>>> made myself clear enough: i am not asking for a new version
>>>> (because you
>>>> told me that it was not possible). I just need some information/
>>>> idea in
>>>> order for me to fix this. If unison just crash when encounting the
>>>> error on Unix/Linux, it will be enough for me...
>>>
>>> There was extensive discussion of possible solutions on this list a
>>> few weeks ago.  The final proposed design was to add a preference for
>>> specifying a "mount point" within the replicas (the default would be
>>> just the empty path) that is expected always to exist on both hosts;
>>> before any changes are transferred, this will be checked, and the run
>>> will be aborted if it is missing.  Implementation of this idea should
>>> be pretty easy.
>>>
>>
>>
>> OK, i go through the archive and try to make a plan to solve this bug.
>> Here it is :
>> - add an option to check presence of files/directories in the two  
>> root in
>>   the configuration file + command line,
>> - if a file is detected as deleted, check the presence of
>>   files/directories, to be sure the deletion doesn't come from a media
>>   disappearance,
>> - if one of the files/directories is not here -> abort,
>> - otherwise, continue,
>>
>> There was also another approach where while scanning, you try to  
>> detect
>> the device number and remember it... Maybe it could also be used, as a
>> way to generate the files/directories option automatically ? I think
>> that unison open a dir before scanning the file, which could be  
>> used to
>> check the device number. So if a file under a particular mount point
>> need to be deleted, unison can check that the media is not gone. If  
>> all
>> the file are on the same mount point, it will default to the root dir.
>>
>> So, i need to know what option name you want ?
>>
>> If i produce a patch, do you think you should integrate it in unison ?
>>
>> Any comments, suggestions ?
>>
>> Regard
>> Sylvain Le Gall
>>
>> ps: i hope you don't get upset about this, i really appreciate your  
>> work
>> on unison, which is a great software -- hope the content of my mail
>> doesn't suggest anything else.
>>