parent
bb4f2af602
commit
da0a696c96
2 changed files with 4 additions and 20 deletions
|
@ -247,6 +247,10 @@ test runannex mkr mkk =
|
||||||
, check "storeKey when already present" $ \r k ->
|
, check "storeKey when already present" $ \r k ->
|
||||||
whenwritable r $ runBool (store r k)
|
whenwritable r $ runBool (store r k)
|
||||||
, check ("present " ++ show True) $ \r k -> present r k True
|
, check ("present " ++ show True) $ \r k -> present r k True
|
||||||
|
, check "retrieveKeyFile" $ \r k -> do
|
||||||
|
lockContentForRemoval k noop removeAnnex
|
||||||
|
get r k
|
||||||
|
, check "fsck downloaded object" fsck
|
||||||
, check "retrieveKeyFile resume from 0" $ \r k -> do
|
, check "retrieveKeyFile resume from 0" $ \r k -> do
|
||||||
tmp <- fromRawFilePath <$> prepTmp k
|
tmp <- fromRawFilePath <$> prepTmp k
|
||||||
liftIO $ writeFile tmp ""
|
liftIO $ writeFile tmp ""
|
||||||
|
@ -270,10 +274,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" $ \r k -> do
|
|
||||||
lockContentForRemoval k noop removeAnnex
|
|
||||||
get r k
|
|
||||||
, check "fsck downloaded object" fsck
|
|
||||||
, check "removeKey when present" $ \r k ->
|
, check "removeKey when present" $ \r k ->
|
||||||
whenwritable r $ runBool (remove r k)
|
whenwritable r $ runBool (remove r k)
|
||||||
, check ("present " ++ show False) $ \r k ->
|
, check ("present " ++ show False) $ \r k ->
|
||||||
|
|
|
@ -1,16 +0,0 @@
|
||||||
[[!comment format=mdwn
|
|
||||||
username="joey"
|
|
||||||
subject="""comment 4"""
|
|
||||||
date="2021-04-22T13:40:33Z"
|
|
||||||
content="""
|
|
||||||
Problem is confirmed to not be from the 33% test, the 0% test failed when
|
|
||||||
run before it, also in the removeAnnex part. And removeAnnex didn't change
|
|
||||||
lately, so it seems probably an earlier test sets up the failure.
|
|
||||||
|
|
||||||
I've moved the 0% test to be the first test that retrieves the file, let's
|
|
||||||
see if it succeeds that way, and if so, it must be that retrieveKeyFile is
|
|
||||||
leaking a file handle, despite using withBinaryFile which is supposed to
|
|
||||||
close handles automatically.
|
|
||||||
|
|
||||||
ghc version used for this windows build is 8.8.4 btw.
|
|
||||||
"""]]
|
|
Loading…
Reference in a new issue