From 2f509e529e765b878f210fbfe6178bc139736230 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 9 Jun 2022 13:16:39 -0400 Subject: [PATCH] bug report --- ...ails_at_drop_stage_does_not_resume_correctly.mdwn | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 doc/bugs/move_that_fails_at_drop_stage_does_not_resume_correctly.mdwn diff --git a/doc/bugs/move_that_fails_at_drop_stage_does_not_resume_correctly.mdwn b/doc/bugs/move_that_fails_at_drop_stage_does_not_resume_correctly.mdwn new file mode 100644 index 0000000000..b70c81ff8c --- /dev/null +++ b/doc/bugs/move_that_fails_at_drop_stage_does_not_resume_correctly.mdwn @@ -0,0 +1,12 @@ +git-annex move takes care to handle resuming an interrupted move, where the +dest received the object, but the drop did not happen before it was +interrupted. + +But, the more common case than being interrupted with ctrl-c or power loss +is the drop failing due to a network issue. In this case, re-running move +does not let the drop succeed in cases where the original move would have +let the drop succeed. + +The problem is that logMove runs its cleanup action in this case. +So the move.log gets the record of the move cleaned from it. It seems that +the cleanup action should avoid doing that when the move failed. --[[Joey]] -- 2.30.2