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

Ben Franksen bugs at darcs.net
Fri Jul 12 16:56:50 UTC 2019


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

>  - We probably can't protect against all possible failures. 
> Reordering patches could lead to invalid states being created even 
> when a particular linearisation of the repository looked fine.

I don't believe this is so. We know that all re-orderings result in the
same state. The commute cases for the 'move' prim ensure that we locally
maintain file identity and the cases for 'addfile' and 'rmfile' (and
removal, too) ensure that file paths are unique in every state. By
induction this generalizes to sequences (assuming permutivity etc) and
thus to complete repositories. So if we make sure that we never add a
patch to the repo that has an 'addfile x' or 'adddir x' or 'move _ x'
where x collides with an existing (tracked) file (using case-insensitive
comparison on Windows), then the repo should be safe regardless of any
reordering.

(Note to self: state and test a property that expresses invariance and
local uniqueness of file identities.)

> - A patch that both removes A and creates a (or renames A to a) 
> should be considered valid, though it may require careful 
> implementation in apply.

I believe we get that behavior by default if we make the check at the
level of prim patches and percolate upwards. We have to be careful with
Conflictors and Mergers, though: we must check /all/ contained prims,
not only the effect. This is why it is not enough to throw an error
inside 'apply', since apply is normally defined by calling the prim
patch level 'apply' on the 'effect'(*). So this requires a new method.

(*) The fact that patch application goes via 'effect' is, I think, what
makes it impossible to build reliable methods to track file identity
based on it. Thus 'applyToPaths', and the functions in
Darcs.Patch.TouchesFiles that build on it, are doomed to fail in the
presence of conflicts and re-orderings. The fix is the same as for the
proposed filename collision check: don't go via effect, instead
implement the method directly for each RepoPatch type.

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


More information about the darcs-devel mailing list