add back inAnnex check after seeking

The test suite noticed this case, where two files with the same key are
dropped, and the seek stage sees both have content due to the way files
stream through it. But then locking the content to drop fails on the
second file, because the first file has already been dropped.

So, add back otherwise redundant inAnnex check.
This commit is contained in:
Joey Hess 2020-07-25 11:18:50 -04:00
parent 00c5f04f20
commit c30fd24d91
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 8 additions and 4 deletions

View file

@ -119,8 +119,7 @@ handleDropsFrom locs rs reason fromhere key afile preverified runner = do
)
dropl fs n = checkdrop fs n Nothing $ \numcopies ->
stopUnless (inAnnex key) $
Command.Drop.startLocal afile ai numcopies key preverified
Command.Drop.startLocal afile ai numcopies key preverified
dropr fs r n = checkdrop fs n (Just $ Remote.uuid r) $ \numcopies ->
Command.Drop.startRemote afile ai numcopies key r

View file

@ -99,8 +99,13 @@ startKeys o from (key, ai) = start' o from key (AssociatedFile Nothing) ai
startLocal :: AssociatedFile -> ActionItem -> NumCopies -> Key -> [VerifiedCopy] -> CommandStart
startLocal afile ai numcopies key preverified =
starting "drop" (OnlyActionOn key ai) $
performLocal key afile numcopies preverified
-- This is a redundant check, because checkContentPresent was
-- enabled when seeking. However, when two files have the same key,
-- the content may have already been removed, which would cause
-- this to fail, so it has to be checked again.
stopUnless (inAnnex key) $
starting "drop" (OnlyActionOn key ai) $
performLocal key afile numcopies preverified
startRemote :: AssociatedFile -> ActionItem -> NumCopies -> Key -> Remote -> CommandStart
startRemote afile ai numcopies key remote =