reorder tests debugging windows failure

This order will work just as well, so no need to revert this change
later.

diff --git a/Command/TestRemote.hs b/Command/TestRemote.hs
index 59a8d24784dd15d4f57150a7bb7461048b3ae3a3..43aa615b4d71e9c7147a8c37faf2d7d783334135 100644 (file)
--- a/Command/TestRemote.hs
+++ b/Command/TestRemote.hs
@@ -251,6 +251,12 @@ test runannex mkr mkk =
                lockContentForRemoval k noop removeAnnex
                get r k
        , check "fsck downloaded object" fsck
+       , check "retrieveKeyFile resume from 0" $ \r k -> do
+               tmp <- fromRawFilePath <$> prepTmp k
+               liftIO $ writeFile tmp ""
+               lockContentForRemoval k noop removeAnnex
+               get r k
+       , check "fsck downloaded object" fsck
        , check "retrieveKeyFile resume from 33%" $ \r k -> do
                loc <- fromRawFilePath <$> Annex.calcRepo (gitAnnexLocation k)
                tmp <- fromRawFilePath <$> prepTmp k
@@ -261,12 +267,6 @@ test runannex mkr mkk =
                lockContentForRemoval k noop removeAnnex
                get r k
        , check "fsck downloaded object" fsck
-       , check "retrieveKeyFile resume from 0" $ \r k -> do
-               tmp <- fromRawFilePath <$> prepTmp k
-               liftIO $ writeFile tmp ""
-               lockContentForRemoval k noop removeAnnex
-               get r k
-       , check "fsck downloaded object" fsck
        , check "retrieveKeyFile resume from end" $ \r k -> do
                loc <- fromRawFilePath <$> Annex.calcRepo (gitAnnexLocation k)
                tmp <- fromRawFilePath <$> prepTmp k

diff --git a/doc/bugs/tests_fail_on_windows__58___retrieveKeyFile_resume/comment_3_4b090a931f9a7210510f17bd31a7ab9c._comment b/doc/bugs/tests_fail_on_windows__58___retrieveKeyFile_resume/comment_3_4b090a931f9a7210510f17bd31a7ab9c._comment
new file mode 100644 (file)
index 0000000..fa130d0
--- /dev/null
+++ b/doc/bugs/tests_fail_on_windows__58___retrieveKeyFile_resume/comment_3_4b090a931f9a7210510f17bd31a7ab9c._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-04-21T16:21:15Z"
+ content="""
+Note that, before it fails, retrieveKeyFile has already succeeded once.
+
+It may be that the cause is that the earlier retrieveKeyFile leaves
+the annex object file somehow inaccessible.
+
+Or it may be that the cause is in Command.TestRemote's code
+that sets up this "resume from 33%" test case:
+
+                loc <- fromRawFilePath <$> Annex.calcRepo (gitAnnexLocation k)
+                tmp <- fromRawFilePath <$> prepTmp k
+                partial <- liftIO $ bracket (openBinaryFile loc ReadMode) hClose $ \h -> do
+                        sz <- hFileSize h
+                        L.hGet h $ fromInteger $ sz `div` 3
+                liftIO $ L.writeFile tmp partial
+               lockContentForRemoval k noop removeAnnex -- appears that this is what fails to delete the file
+
+If the handle that is opened to read the annex object file somehow
+causes it to linger in a locked state past when the handle should be closed,
+it could cause the later failure to delete the annex object file, since windows
+may consider an open file handle to be a lock.
+
+(Some issues with ghc not promptly closing file handles, in a version
+in the last year or so, come to mind..)
+
+I've swapped the order of the resume from 33% and resume from 0%
+tests. The 0% test does not open a handle that way. So if the
+resume from 0% still fails, we'll know for sure the problem is not
+caused by the 33% test.
+
+If it is caused by the CoW changes, it seems likely to involve fileCopier's
+code that tries to preserve the source file's mode. Before the CoW
+changes, I don't think that was done by Remote.Directory's retrieveKeyFile.
+"""]]