bugfix: drop --from an unavailable remote no longer updates the location log, incorrectly, to say the remote does not have the key.

The comments correctly noted that the remote could drop the key and
yet False be returned due to some problem that occurred afterwards.
For example, if it's a network remote, it could drop the key just
as the network goes down, and so things timeout and a nonzero exit
from ssh is propigated through and False returned.

However... Most of the time, this scenario will not have happened.
False will mean the remote was not available or could not drop the key
at all.

So, instead of assuming the worst, just trust the status we have.

If we get it wrong, and the scenario above happened, our location
log will think the remote has the key. But the remote's location
log (assuming it has one) will know it dropped it, and the next sync
will regain consistency.

For a special remote, with no location log, our location log will be wrong,
but this is no different than the situation where someone else dropped
the key from the remote and we've not synced with them. The standard
paranoia about not trusting the location log to be the last word about
whether a remote has a key will save us from these situations. Ie,
if we try to drop the file, we'll actively check the remote,
and determine the inconsistency then.

Command/Drop.hs

@@ -89,10 +89,8 @@ cleanupLocal key = do
 
 cleanupRemote :: Key -> Remote -> Bool -> CommandCleanup
 cleanupRemote key remote ok = do
-	-- better safe than sorry: assume the remote dropped the key
-	-- even if it seemed to fail; the failure could have occurred
-	-- after it really dropped it
-	Remote.logStatus remote key InfoMissing
+	when ok $
+		Remote.logStatus remote key InfoMissing
 	return ok
 
 {- Checks specified remotes to verify that enough copies of a key exist to

Command/Fsck.hs

@@ -401,10 +401,8 @@ badContentDirect file key = do
 badContentRemote :: Remote -> Key -> Annex String
 badContentRemote remote key = do
 	ok <- Remote.removeKey remote key
-	-- better safe than sorry: assume the remote dropped the key
-	-- even if it seemed to fail; the failure could have occurred
-	-- after it really dropped it
-	Remote.logStatus remote key InfoMissing
+	when ok $
+		Remote.logStatus remote key InfoMissing
 	return $ (if ok then "dropped from " else "failed to drop from ")
 		++ Remote.name remote
 

debian/changelog

@@ -40,6 +40,8 @@ git-annex (4.20130228) UNRELEASED; urgency=low
     that caused regular browsers to stall when they reuse a connection
     after leaving it idle for 30 seconds.
     (See https://github.com/yesodweb/wai/issues/146)
+  * bugfix: drop --from an unavailable remote no longer updates the location
+    log, incorrectly, to say the remote does not have the key.
 
  -- Joey Hess <joeyh@debian.org>  Wed, 27 Feb 2013 23:20:40 -0400