D7199: lock: fix race in lock-breaking code

[valentin.gatienbaron (Valentin Gatien-Baron)]

valentin.gatienbaron added a comment.


  Thanks for the review. Did something go wrong in a rebase? I'm confused as to why there's two `self.vfs.unlink` calls in the diff displayed by phabricator.
  
  I have read the paper you mention, and I have seen repositories get corrupted for these kinds of reasons (revlog index's length may get written without the corresponding data if the machine reboots, transaction commits but fncache gets truncated when one runs out of disk space). But I don't think it talks of locking problems in the absence of crashes, as is happening here. The ordering of filesystem operations in-memory is stricter.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7199/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7199

To: valentin.gatienbaron, #hg-reviewers, indygreg
Cc: indygreg, mercurial-devel