content removal is supposed to succed if the content was already not present
This commit is contained in:
parent
ca1bcdcd7c
commit
71e8cd408e
2 changed files with 8 additions and 7 deletions
12
P2P/Annex.hs
12
P2P/Annex.hs
|
@ -91,10 +91,14 @@ runLocal runmode runner a = case a of
|
|||
Left e -> return (Left (show e))
|
||||
Right result -> runner (next result)
|
||||
RemoveContent k next -> do
|
||||
v <- tryNonAsync $ lockContentForRemoval k $ \contentlock -> do
|
||||
removeAnnex contentlock
|
||||
logStatus k InfoMissing
|
||||
return True
|
||||
v <- tryNonAsync $
|
||||
ifM (Annex.Content.inAnnex key)
|
||||
( lockContentForRemoval k $ \contentlock -> do
|
||||
removeAnnex contentlock
|
||||
logStatus k InfoMissing
|
||||
return True
|
||||
, return True
|
||||
)
|
||||
case v of
|
||||
Left e -> return (Left (show e))
|
||||
Right result -> runner (next result)
|
||||
|
|
|
@ -12,9 +12,6 @@ Current todo list:
|
|||
object is already in progress, the message about this is output by the
|
||||
remotedaemon --debug, but not forwarded to the peer, which shows
|
||||
"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
|
||||
is dropped while we think we're locking content there from being dropped?
|
||||
|
||||
|
|
Loading…
Reference in a new issue