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

[Ben Franksen]

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

> change the Eq and Ord instances for 
> AnchoredPath (at compile time, depending on the target OS) so that 
> on Windows AnchoredPaths that differ only in case compare equal. The 
> obvious problem with that is that upper/lower case depends on the 
> encoding, so patch semantics (how patches commute and merge) now may 
> depend on the encoding that is being used by the file system.

Okay, I was thinking out loud. So this is not a solution. Whether two
patches conflict (or commute or merge cleanly) should not depend on
which OS we do the merge on. I think we can take this as an axiom.

It follows that, on Windows, Darcs must refuse to apply any patch
containing a path that differs only in case from any existing path in
pristine or working in order to prevent the working tree to become
corrupt. In general this invariant must also be checked when we clone a
repo, otherwise we will get this sort of failure later when we operate
on the history (obliterate, amend, test, etc). On non-Windows OSes doing
these checks is optional, useful in case the user wants full
interoperability with Windows.

The check during clone could be done when we build a patch index. If
that is disabled, we must resort to a built-in 'darcs check' as part of
the clone command. I guess the actual 'darcs check/repair' should also
check the invariant (again on Windows this would be mandatory, otherwise
optional).

I could imagine a configuration option (or an interactive yes/no prompt)
that allows the user to override the decision (after doing the check and
displaying its result, and with appropriate warnings attached). This
would mainly be for cases where collisions happened only in the distant
past so that it is unlikely they will be encountered in practice when
working with the repo.

BTW, I am not convinced adopting FileUUID would solve the problem, at
least not fully. We do have to mention file names, if not full paths, in
patches: on Windows two Manifest patches should conflict when they place
two objects as "foo" and "FOO" in the same directory object (otherwise
the result could not be converted to a valid working tree), whereas on
Linux this would not be a conflict. Again we cannot allow that, so on
Windows we must refuse to apply two such prims.

The very least we must do to resolve the issue at hand is to detect when
we are about to apply such an 'invalid' (relative to the current repo
state) patch and fail with an appropriate error message.

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