largefiles: handle that a found standin file doesn't exist when removing it stable
authorMads Kiilerich <>
Thu, 27 Oct 2016 20:06:33 +0200
changeset 33726 3afde791dce192f38d8a228ed8e49397e353837e
parent 33725 362740e054609d55dea1403ce5fdfcb1379403fb
child 33727 34a5f6c66bc5a13381a68d08f73d858916167836
push id365
push dateTue, 01 Nov 2016 02:33:44 +0000
largefiles: handle that a found standin file doesn't exist when removing it I somehow ended up in a situation where hg crashed on an unlink I introduced in 328545c7d8a1. I don't know how it happened and can't reproduce it. It seems like it only can happen when the file is removed between the time of check in a working directory context walk that finds a standin file, and the time of use when we try to remove it because the corresponding largefile doesn't exist. But better safe than sorry: replace the plain unlink with unlinkpath with ignoremissing=True. That will also remove remaining empty directories, which arguably is more correct.
--- a/hgext/largefiles/
+++ b/hgext/largefiles/
@@ -212,17 +212,17 @@ def reposetup(ui, repo):
                         if not match(lfile):
                         if lfile not in lfdirstate:
                             # Sync "largefile has been removed" back to the
                             # standin. Removing a file as a side effect of
                             # running status is gross, but the alternatives (if
                             # any) are worse.
-                            self.wvfs.unlink(standin)
+                            self.wvfs.unlinkpath(standin, ignoremissing=True)
                     # Filter result lists
                     result = list(result)
                     # Largefiles are not really removed when they're
                     # still in the normal dirstate. Likewise, normal
                     # files are not really removed if they are still in
                     # lfdirstate. This happens in merges where files