From: Joey Hess Date: Mon, 19 Oct 2020 18:57:02 +0000 (-0400) Subject: design done X-Git-Tag: archive/raspbian/10.20250416-2+rpi1~1^2~106^2~76 X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=15ea0e6c0ac56b13ee911d3c45d13b1b27119b0f;p=git-annex.git design done --- diff --git a/doc/todo/interruped_move_resume.mdwn b/doc/todo/interruped_move_resume.mdwn index dae5f8c15f..41cd23206f 100644 --- a/doc/todo/interruped_move_resume.mdwn +++ b/doc/todo/interruped_move_resume.mdwn @@ -10,6 +10,9 @@ numcopies is 2, so it can't drop the copy from the remote. This happens to me often enough to be annoying. +I think it can also happen with move --to, although I can't remember seeing +that. + Perhaps some local state could avoid this problem? --[[Joey]] @@ -48,3 +51,13 @@ Perhaps some local state could avoid this problem? > > Still, if the move is interrupted and never resumed, after a sync > > with the remote, the only copy appears missing, which does seem > > potentially confusing. + +> Local state could be a file listing keys that have had a move started +> but not finished. When doing the same move, it should be allowed to +> succeed even if numcopies would prevent it. More accurately, it +> should disregard the local copy when checking numcopies for a move +> --from. And for a move --to, it should disregard the remote copy. +> May need 2 separate lists for the two kinds of moves. +> +> > This is complex to implement, but it avoids the gotchas in the earlier +> > ideas, so I think is best. --[[Joey]]