diff --git a/doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only/comment_1_e03ec3be310f5c0e02457ac053e6afdd._comment b/doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only/comment_1_e03ec3be310f5c0e02457ac053e6afdd._comment
new file mode 100644
index 0000000000..b8d0c38c63
--- /dev/null
+++ b/doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only/comment_1_e03ec3be310f5c0e02457ac053e6afdd._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-06-11T17:36:54Z"
+ content="""
+The reason git-annex is preventing you from dropping a file in this
+situation can be understood if you imagine that you've given me and a
+friend access to your remotes.
+
+Each of the three of us runs git-annex drop --from one remote. We all
+picked a different remote. So each git-annex, running at the same time,
+see two copies of the file, so assume they can delete the third copy. 
+And so all 3 copies get deleted.
+
+Admittedly, this is more likely to happen if there are only 2 remotes and 2
+people involved, not 3 or more, and would be a big cooincidence even with
+2 people. But git-annex aims to avoid losing content even in unlikely cases.
+
+So it requires that, in order to drop the file, at least one of the other
+repos have a copy, and be able to lock it in place, preventing it from
+being dropped from that repo.
+
+Unfortunately, the only remote that can lock content currently is a
+git repository. (Maybe that [[could be improved|todo/lockContent_for_special_remotes]].)
+
+The solution for you it to either use --force like the message says
+(only if you're sure nobody else is dropping the files from the other remotes
+at the same time), or to also have a git remote somewhere that contains
+the file.
+"""]]
diff --git a/doc/todo/lockContent_for_special_remotes.mdwn b/doc/todo/lockContent_for_special_remotes.mdwn
new file mode 100644
index 0000000000..cee9ce4341
--- /dev/null
+++ b/doc/todo/lockContent_for_special_remotes.mdwn
@@ -0,0 +1,18 @@
+Currently only Remote.Git implements lockContent. It seems like some other
+special remotes can lock content though:
+
+* bup and git-lfs and tahoe can't drop content, so content is implicitly locked
+* S3 has an object lock feature, I don't know if it would be usable for
+  this, but woth investigating.
+* web can't drop content, so content is also implicitly locked there
+  (of course web is often untrusted so git-annex won't count it as a copy
+  anyway then)
+* appendonly remotes can't drop content. This includes S3 repos configured
+  with versioning. It would be worth either giving all such remotes a
+  lockContent that succeeds noop, or just checking for appendonly the same
+  places lockContent is used.
+* directory could use fcntl locking
+* adb could use some shell trick perhaps
+* It might be possible for an external remote to lock content, but it would
+  be a tricky extension to the protocol, since lockContent needs to keep it
+  locked while running another action.