tests and verified that the bug is fixed, in all the cases I identified

This commit is contained in:
Joey Hess 2015-10-09 15:59:42 -04:00
parent 6a72045707
commit b944da832b
Failed to extract signature
2 changed files with 8 additions and 5 deletions

View file

@ -20,8 +20,6 @@ import Annex.Content
import Annex.Wanted import Annex.Wanted
import Annex.Notification import Annex.Notification
import Utility.ThreadScheduler
import System.Log.Logger (debugM) import System.Log.Logger (debugM)
import qualified Data.Set as S import qualified Data.Set as S
@ -99,7 +97,7 @@ performLocal key afile numcopies preverified = lockContentForRemoval key $ \cont
( \proof -> do ( \proof -> do
liftIO $ debugM "drop" $ unwords liftIO $ debugM "drop" $ unwords
[ "Dropping from here" [ "Dropping from here"
, "proof: " , "proof:"
, show proof , show proof
] ]
removeAnnex contentlock removeAnnex contentlock
@ -125,8 +123,6 @@ performRemote key afile numcopies remote = do
, "proof: " , "proof: "
, show proof , show proof
] ]
liftIO $ print "waiting to drop.."
liftIO $ threadDelaySeconds (Seconds 10)
ok <- Remote.removeKey remote key ok <- Remote.removeKey remote key
next $ cleanupRemote key remote ok next $ cleanupRemote key remote ok
, stop , stop

View file

@ -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, 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). it'll be locked and that'll fail (and vice-versa).
> Done, and verified the fix works in this situation.
# the bug part 2 # the bug part 2
<pre> <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 the change is from checking if content is in a location, to locking it in
that location while performing a drop from another location. 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) # the bug part 3 (where it gets really nasty)
<pre> <pre>
@ -198,6 +202,9 @@ never entirely lost.
Dipping below desired numcopies in an unusual race condition, and then Dipping below desired numcopies in an unusual race condition, and then
doing extra work later to recover may be good enough. 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 ### to drop from local repo
When dropping an object from the local repo, lock it for drop, When dropping an object from the local repo, lock it for drop,