mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

reorder tests debugging windows failure

Browse source 
This order will work just as well, so no need to revert this change
later.
This commit is contained in:
Joey Hess 2021-04-21 13:01:41 -04:00
parent 430c5a15f5
commit 39d94919cd
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 44 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

12
Command/TestRemote.hs
View file

@ -251,6 +251,12 @@ test runannex mkr mkk =
lockContentForRemoval k noop removeAnnex lockContentForRemoval k noop removeAnnex
get r k get r k
, check "fsck downloaded object" fsck , 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 , check "retrieveKeyFile resume from 33%" $ \r k -> do
loc <- fromRawFilePath <$> Annex.calcRepo (gitAnnexLocation k) loc <- fromRawFilePath <$> Annex.calcRepo (gitAnnexLocation k)
tmp <- fromRawFilePath <$> prepTmp k tmp <- fromRawFilePath <$> prepTmp k
@ -261,12 +267,6 @@ test runannex mkr mkk =
lockContentForRemoval k noop removeAnnex lockContentForRemoval k noop removeAnnex
get r k get r k
, check "fsck downloaded object" fsck , 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 , check "retrieveKeyFile resume from end" $ \r k -> do
loc <- fromRawFilePath <$> Annex.calcRepo (gitAnnexLocation k) loc <- fromRawFilePath <$> Annex.calcRepo (gitAnnexLocation k)
tmp <- fromRawFilePath <$> prepTmp k tmp <- fromRawFilePath <$> prepTmp k

38
doc/bugs/tests_fail_on_windows__58___retrieveKeyFile_resume/comment_3_4b090a931f9a7210510f17bd31a7ab9c._comment Normal file
View file

@ -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.
"""]]