diff --git a/doc/bugs/Running_fsck_on_a_remote_drops_bad_files.mdwn b/doc/bugs/Running_fsck_on_a_remote_drops_bad_files.mdwn
index 9770a1967a..1fe67798e7 100644
--- a/doc/bugs/Running_fsck_on_a_remote_drops_bad_files.mdwn
+++ b/doc/bugs/Running_fsck_on_a_remote_drops_bad_files.mdwn
@@ -35,3 +35,5 @@ git-annex: fsck: 1 failed
 
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 Yes it stores most of my data
+
+> [[notabug|done]] --[[Joey]]
diff --git a/doc/bugs/Running_fsck_on_a_remote_drops_bad_files/comment_1_c75030329f9769e557aba68193ce1801._comment b/doc/bugs/Running_fsck_on_a_remote_drops_bad_files/comment_1_c75030329f9769e557aba68193ce1801._comment
new file mode 100644
index 0000000000..61476408ce
--- /dev/null
+++ b/doc/bugs/Running_fsck_on_a_remote_drops_bad_files/comment_1_c75030329f9769e557aba68193ce1801._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-06-30T14:33:08Z"
+ content="""
+The corrupted file is downloaded from the remote, and that copy of the file
+gets moved to .git/annex/bad/ when fsck determines it's corrupt. A message
+is displayed giving the path where the content is left.
+
+The only time that's not done is if the local repository has its own copy
+of the file. In that case, there's not much benefit to accumulating bad
+copies in .git/annex/bad since there's still a (presumably) good copy.
+
+If fsck left corrupted content on the remote, that would risk actual data
+loss. Consider if a second repository also had access to the remote, and
+in that repository you ran git-annex drop. It would see that the remote
+still contains the file, so assume the content is good, and so go ahead and
+drop the content from the second repository. That might be the only
+uncorrupted copy of the file it's lost. So once we know that the content is
+corrupt, the safe thing to do is move it out of the way.
+"""]]