content removal is supposed to succed if the content was already not present

This commit is contained in:
Joey Hess 2016-12-09 12:47:57 -04:00
parent ca1bcdcd7c
commit 71e8cd408e
No known key found for this signature in database
GPG key ID: C910D9222512E3C7
2 changed files with 8 additions and 7 deletions

View file

@ -91,10 +91,14 @@ runLocal runmode runner a = case a of
Left e -> return (Left (show e)) Left e -> return (Left (show e))
Right result -> runner (next result) Right result -> runner (next result)
RemoveContent k next -> do RemoveContent k next -> do
v <- tryNonAsync $ lockContentForRemoval k $ \contentlock -> do v <- tryNonAsync $
removeAnnex contentlock ifM (Annex.Content.inAnnex key)
logStatus k InfoMissing ( lockContentForRemoval k $ \contentlock -> do
return True removeAnnex contentlock
logStatus k InfoMissing
return True
, return True
)
case v of case v of
Left e -> return (Left (show e)) Left e -> return (Left (show e))
Right result -> runner (next result) Right result -> runner (next result)

View file

@ -12,9 +12,6 @@ Current todo list:
object is already in progress, the message about this is output by the object is already in progress, the message about this is output by the
remotedaemon --debug, but not forwarded to the peer, which shows remotedaemon --debug, but not forwarded to the peer, which shows
"Connection reset by peer" "Connection reset by peer"
* git annex drop --from peer1, when the peer does not have a file,
shows "<socket: 18>: hGetLine: end of file"; the peer has closed the
connection.
* Think about locking some more. What happens if the connection to the peer * Think about locking some more. What happens if the connection to the peer
is dropped while we think we're locking content there from being dropped? is dropped while we think we're locking content there from being dropped?