diff options
| -rw-r--r-- | Command/Drop.hs | 6 | ||||
| -rw-r--r-- | doc/bugs/concurrent_drop--from_presence_checking_failures.mdwn | 7 |
2 files changed, 8 insertions, 5 deletions
diff --git a/Command/Drop.hs b/Command/Drop.hs index d14cdad18..5bbaf11c6 100644 --- a/Command/Drop.hs +++ b/Command/Drop.hs @@ -20,8 +20,6 @@ import Annex.Content import Annex.Wanted import Annex.Notification -import Utility.ThreadScheduler - import System.Log.Logger (debugM) import qualified Data.Set as S @@ -99,7 +97,7 @@ performLocal key afile numcopies preverified = lockContentForRemoval key $ \cont ( \proof -> do liftIO $ debugM "drop" $ unwords [ "Dropping from here" - , "proof: " + , "proof:" , show proof ] removeAnnex contentlock @@ -125,8 +123,6 @@ performRemote key afile numcopies remote = do , "proof: " , show proof ] - liftIO $ print "waiting to drop.." - liftIO $ threadDelaySeconds (Seconds 10) ok <- Remote.removeKey remote key next $ cleanupRemote key remote ok , stop diff --git a/doc/bugs/concurrent_drop--from_presence_checking_failures.mdwn b/doc/bugs/concurrent_drop--from_presence_checking_failures.mdwn index 7b38af13c..22e50766a 100644 --- a/doc/bugs/concurrent_drop--from_presence_checking_failures.mdwn +++ b/doc/bugs/concurrent_drop--from_presence_checking_failures.mdwn @@ -73,6 +73,8 @@ as part of its check of numcopies, and keep it locked while it's asking B to drop it. Then when B tells A to drop it, it'll be locked and that'll fail (and vice-versa). +> Done, and verified the fix works in this situation. + # the bug part 2 <pre> @@ -116,6 +118,8 @@ Note that this is analgous to the fix above; in both cases the change is from checking if content is in a location, to locking it in that location while performing a drop from another location. +> Done, and verified the fix works in this situation. + # the bug part 3 (where it gets really nasty) <pre> @@ -198,6 +202,9 @@ never entirely lost. Dipping below desired numcopies in an unusual race condition, and then doing extra work later to recover may be good enough. +> Implemented, and I've now verified this solves the case above. +> Indeed, neither drop succeeds, because no copy can be locked. + ### to drop from local repo When dropping an object from the local repo, lock it for drop, |