dgit.raspbian.org Git - git-annex.git/blob

   1 [[!comment format=mdwn
   2  username="joey"
   3  subject="""comment 3"""
   4  date="2021-04-21T16:21:15Z"
   5  content="""
   6 Note that, before it fails, retrieveKeyFile has already succeeded once.
   7
   8 It may be that the cause is that the earlier retrieveKeyFile leaves
   9 the annex object file somehow inaccessible.
  10
  11 Or it may be that the cause is in Command.TestRemote's code
  12 that sets up this "resume from 33%" test case:
  13
  14                 loc <- fromRawFilePath <$> Annex.calcRepo (gitAnnexLocation k)
  15                 tmp <- fromRawFilePath <$> prepTmp k
  16                 partial <- liftIO $ bracket (openBinaryFile loc ReadMode) hClose $ \h -> do
  17                         sz <- hFileSize h
  18                         L.hGet h $ fromInteger $ sz `div` 3
  19                 liftIO $ L.writeFile tmp partial
  20                 lockContentForRemoval k noop removeAnnex -- appears that this is what fails to delete the file
  21
  22 If the handle that is opened to read the annex object file somehow
  23 causes it to linger in a locked state past when the handle should be closed,
  24 it could cause the later failure to delete the annex object file, since windows
  25 may consider an open file handle to be a lock.
  26
  27 (Some issues with ghc not promptly closing file handles, in a version
  28 in the last year or so, come to mind..)
  29
  30 I've swapped the order of the resume from 33% and resume from 0%
  31 tests. The 0% test does not open a handle that way. So if the
  32 resume from 0% still fails, we'll know for sure the problem is not
  33 caused by the 33% test.
  34
  35 If it is caused by the CoW changes, it seems likely to involve fileCopier's
  36 code that tries to preserve the source file's mode. Before the CoW
  37 changes, I don't think that was done by Remote.Directory's retrieveKeyFile.
  38 """]]