diff options
author | 2013-03-10 19:15:53 -0400 | |
---|---|---|
committer | 2013-03-10 19:15:53 -0400 | |
commit | 8d4c52d05f540bb9f7e2e305e650b64357dfeb39 (patch) | |
tree | 0ef1eebfe655a3284d044c58323452cdc08156dd | |
parent | d2a8d2dfd783541e682cad15ec70ae277a036635 (diff) |
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.
-rw-r--r-- | Command/Drop.hs | 6 | ||||
-rw-r--r-- | Command/Fsck.hs | 6 | ||||
-rw-r--r-- | debian/changelog | 2 |
3 files changed, 6 insertions, 8 deletions
diff --git a/Command/Drop.hs b/Command/Drop.hs index 5699175ed..1d09ca3fd 100644 --- a/Command/Drop.hs +++ b/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 diff --git a/Command/Fsck.hs b/Command/Fsck.hs index a27588482..aeed58cd1 100644 --- a/Command/Fsck.hs +++ b/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 diff --git a/debian/changelog b/debian/changelog index 75299cf39..31cc06000 100644 --- a/debian/changelog +++ b/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 |