design done
authorJoey Hess <joeyh@joeyh.name>
Mon, 19 Oct 2020 18:57:02 +0000 (14:57 -0400)
committerJoey Hess <joeyh@joeyh.name>
Mon, 19 Oct 2020 18:57:02 +0000 (14:57 -0400)
doc/todo/interruped_move_resume.mdwn

index dae5f8c15fe0b947b0621e79b8eff00090605fad..41cd23206f0c7cb72599b92cddef787d62b4c2b1 100644 (file)
@@ -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]]