diff --git a/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_17_225c1890457835884f9a46359935c0b0._comment b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_17_225c1890457835884f9a46359935c0b0._comment
new file mode 100644
index 0000000000..dd25285d7d
--- /dev/null
+++ b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_17_225c1890457835884f9a46359935c0b0._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="jkniiv@b330fc3a602d36a37a67b2a2d99d4bed3bb653cb"
+ nickname="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/419f2eee8b0c37256488fabcc2737ff2"
+ subject="`git annex sync --no-commit --content` takes double the time of `git annex get .`"
+ date="2021-08-20T02:05:53Z"
+ content="""
+Hi Joey! Could you think of a reason why a `git annex sync --no-commit --content` takes pretty
+much double the time to retrieve an annexed file than a `git annex get .` in the same directory /
+git remote with this one file added in origin? Naturally I drop the file inbetween measurements
+and my files are of multi-gigabyte size so the delay is really noticeable between two HDDs.
+It seems that the extra time (and disk activity) takes place after the retrieval has hit 100% so
+to me it feels like git-annex is doing an extra verification pass after copying the file. This is
+on Windows and git-annex is a fresh `8.20210804-g492036622` but I seem to have noticed it
+happening even before your latest development activities above (as in months ago). Should I
+file a bug report about this?
+
+"""]]