From 15ea0e6c0ac56b13ee911d3c45d13b1b27119b0f Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 19 Oct 2020 14:57:02 -0400 Subject: [PATCH] design done --- doc/todo/interruped_move_resume.mdwn | 13 +++++++++++++ 1 file changed, 13 insertions(+) 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]] -- 2.39.5