From 39d94919cd0f4def5d1a8a3cd40135108f687704 Mon Sep 17 00:00:00 2001
From: Joey Hess <joeyh@joeyh.name>
Date: Wed, 21 Apr 2021 13:01:41 -0400
Subject: [PATCH] reorder tests debugging windows failure

This order will work just as well, so no need to revert this change
later.
---
 Command/TestRemote.hs                         | 12 +++---
 ..._4b090a931f9a7210510f17bd31a7ab9c._comment | 38 +++++++++++++++++++
 2 files changed, 44 insertions(+), 6 deletions(-)
 create mode 100644 doc/bugs/tests_fail_on_windows__58___retrieveKeyFile_resume/comment_3_4b090a931f9a7210510f17bd31a7ab9c._comment

diff --git a/Command/TestRemote.hs b/Command/TestRemote.hs
index 59a8d24784..43aa615b4d 100644
--- 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
index 0000000000..fa130d0162
--- /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.
+"""]]