From 7b37f2288032519efa106f74f5632e3bd6e53ba7 Mon Sep 17 00:00:00 2001 From: "lykos@d125a37d89b1cfac20829f12911656c40cb70018" Date: Tue, 29 Sep 2020 08:36:19 +0000 Subject: [PATCH] Added a comment --- ..._5228016c35ca0b13545b82bbd3b9455e._comment | 20 +++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 doc/todo/CHECKPRESENT-MULTI/comment_4_5228016c35ca0b13545b82bbd3b9455e._comment diff --git a/doc/todo/CHECKPRESENT-MULTI/comment_4_5228016c35ca0b13545b82bbd3b9455e._comment b/doc/todo/CHECKPRESENT-MULTI/comment_4_5228016c35ca0b13545b82bbd3b9455e._comment new file mode 100644 index 0000000000..04c5c71316 --- /dev/null +++ b/doc/todo/CHECKPRESENT-MULTI/comment_4_5228016c35ca0b13545b82bbd3b9455e._comment @@ -0,0 +1,20 @@ +[[!comment format=mdwn + username="lykos@d125a37d89b1cfac20829f12911656c40cb70018" + nickname="lykos" + avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2" + subject="comment 4" + date="2020-09-29T08:36:18Z" + content=""" + +I agree about the simplification. However, when resuming an upload with, say, 400 chunks where only 10 are missing, after CHECKPRESENT-MULTI-FAILURE, we'd need to CHECKPRESENT another 390 keys until we can continue. Sure, the remote could cache the replies, but another idea would be for the remote to reply with the last key in the list that is present. + +Example: + +``` +$ CHECKPRESENT-MULTI a b c d e # git annex calls CHECKPRESENT-MULTI with an ordered list +CHECKPRESENT-MULTI-SUCCESS # all keys are present +CHECKPRESENT-MULTI-FAILURE # all keys are missing +CHECKPRESENT-MULTI-FAILURE c # Everything up to c is present, d is missing. e could be present or missing +``` + +"""]]