[darcs-devel] [issue1461] case-folding can lead to working directory corruption

[Ben Franksen]

Ben Franksen <ben.franksen at online.de> added the comment:

> And you also can never merge a repo that ever created 'a' with a repo
> that ever created 'A'.

Yes, that's the price. Perhaps it is too high.

>>> I'd be surprised if both of the following worked without special care:
>>>
>>> atomic patch containing rm A ; add a
>>> atomic patch containing add a ; rm A
>>
>> Given your refutation, rather than adding this kind of complexity and
>> not even gaining full safety, I think the better solution is the global
>> property. That would mean we forbid a "patch that both removes A and
>> creates a (or renames A to a)". This is straight forward to implement
>> and fully safe, unless the user expressly overrides it with a command
>> line option as I proposed before.
> 
> I think that as it happens all these specific cases (atomic patches that
> add a and remove A, or one that moves A to a) are perfectly safe. The
> atomicity of the patches guarantees they are never both present no
> matter what the patch ordering.

Any patch that conflicts with, say, the 'rm A' will have the effect of
'add A' and will thus be treated... how?

> I've run into situations in practice where fixing the case of files on
> Windows was important, e.g. because a project name is determined by the
> exact name of the project file (including its case).

Okay, you mean you want to be able to record 'move A a'. Yes, that would
be forbidden under the strict regime. I guess it really is a bit too
strict...

> Of course this would only ever be an optional warning so we don't have
> to get it perfect. But my preference would be to err on the side of
> making case changes in a repo pleasant, compared to guarding against the
> much less likely case of commuting generating a dangerous repo.
> 
> TBH I'm probably one of the very few darcs users on Windows and I am not
> desperate for this feature, so it's unlikely to be much of a development
> priority in any case.

As it's "only" the working tree that breaks, perhaps it suffices to
reliably detect the situation and instruct the user that they should
rename or remove one of the files to make the problem go away; and also
warn them that this "fix" may not be permanent i.e. the problem may
re-appear if they re-order patches. That shouldn't be too hard to do.

__________________________________
Darcs bug tracker <bugs at darcs.net>
<http://bugs.darcs.net/issue1461>
__________________________________