fix reversion in recent CoW changes

File handle accidentially left open is both a FD leak and causes the
haskell RTS to reject opening it again with "file is locked".

diff --git a/Remote/Directory.hs b/Remote/Directory.hs
index 195fad0759a8cb744f0860cca885d832a5dbcb4b..8d69f271a36c060cb7b64dc936935d3cab9d3edd 100644 (file)
--- a/Remote/Directory.hs
+++ b/Remote/Directory.hs
@@ -494,7 +494,8 @@ retrieveExportWithContentIdentifierM dir cow loc cid dest mkkey p =
 storeExportWithContentIdentifierM :: RawFilePath -> CopyCoWTried -> FilePath -> Key -> ExportLocation -> [ContentIdentifier] -> MeterUpdate -> Annex ContentIdentifier
 storeExportWithContentIdentifierM dir cow src k loc overwritablecids p = do
        liftIO $ createDirectoryUnder dir (toRawFilePath destdir)
-       withTmpFileIn destdir template $ \tmpf _tmph -> do
+       withTmpFileIn destdir template $ \tmpf tmph -> do
+               liftIO $ hClose tmph
                fileCopierUnVerified cow src tmpf k p
                let tmpf' = toRawFilePath tmpf
                resetAnnexFilePerm tmpf'

diff --git a/doc/bugs/fresh_3_tests_fails-_openBinaryFile__58___resource_busy.mdwn b/doc/bugs/fresh_3_tests_fails-_openBinaryFile__58___resource_busy.mdwn
index 217289ec5a648b943d7896c0481b176a07c4a148..604d333bc87fbec610570b616a65dd323d032393 100644 (file)
--- a/doc/bugs/fresh_3_tests_fails-_openBinaryFile__58___resource_busy.mdwn
+++ b/doc/bugs/fresh_3_tests_fails-_openBinaryFile__58___resource_busy.mdwn
@@ -23,3 +23,5 @@ looked only at "normal" run
 so  actually looks like the same test in various scenarios.
 
 probably relates to the tune ups to make importtree work with CoW
+
+>  [[fixed|done]] --[[Joey]] 

diff --git a/doc/bugs/fresh_3_tests_fails-_openBinaryFile__58___resource_busy/comment_1_d78cd2a78c97a00629aa86b46e72ff67._comment b/doc/bugs/fresh_3_tests_fails-_openBinaryFile__58___resource_busy/comment_1_d78cd2a78c97a00629aa86b46e72ff67._comment
new file mode 100644 (file)
index 0000000..a2eada3
--- /dev/null
+++ b/doc/bugs/fresh_3_tests_fails-_openBinaryFile__58___resource_busy/comment_1_d78cd2a78c97a00629aa86b46e72ff67._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-04-20T15:10:59Z"
+ content="""
+Indeed it was, file handle left open. Fixed.
+"""]]

diff --git a/doc/bugs/tests_fail_on_windows__58___retrieveKeyFile_resume/comment_1_59d56dcb2441f6c69b98605498460896._comment b/doc/bugs/tests_fail_on_windows__58___retrieveKeyFile_resume/comment_1_59d56dcb2441f6c69b98605498460896._comment
new file mode 100644 (file)
index 0000000..1fae9a7
--- /dev/null
+++ b/doc/bugs/tests_fail_on_windows__58___retrieveKeyFile_resume/comment_1_59d56dcb2441f6c69b98605498460896._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-04-20T15:10:00Z"
+ content="""
+It's possible it had the same cause as the other failure, which I've now
+fixed. That involved a file handle leak, and on windows a file handle being
+left open for write is treated the same as the file being locked and will
+prevent a later deletion attempt and also a later write attempt, which
+could explain the two unlike failures.
+
+However, the file that was left open was a temp file in the remote,
+not the object file in the annex. So I'm not sure if it's fixed.
+Also possible something else in the windows code path changed accidentially
+during those CoW changes. Will have to see what happens when the
+autobuilder runs again.
+"""]]