diff --git a/doc/bugs/drop_on_NFS___40__no_pidlock_need_detected__41___leaves_annex__47__objects__47__XX__47__YY__47__KEY_dir_behind_/comment_1_ef17dd348b2404000c29e7b41f1e5253._comment b/doc/bugs/drop_on_NFS___40__no_pidlock_need_detected__41___leaves_annex__47__objects__47__XX__47__YY__47__KEY_dir_behind_/comment_1_ef17dd348b2404000c29e7b41f1e5253._comment
new file mode 100644
index 0000000000..23422d1a81
--- /dev/null
+++ b/doc/bugs/drop_on_NFS___40__no_pidlock_need_detected__41___leaves_annex__47__objects__47__XX__47__YY__47__KEY_dir_behind_/comment_1_ef17dd348b2404000c29e7b41f1e5253._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-02-28T17:39:43Z"
+ content="""
+You should always enable pidlock on NFS.
+
+AFAIK, there has been no particular change to git-annex that prevents .nfs
+files from causing problems when git-annex uses posix file locking.
+There might have been some change in the behavior of a nfs server, eg
+it might delete the .nfs file *eventually*, but only after git-annex
+has tried, and failed, to delete the non-empty key directory. Seems like
+the kind of thing that network latency etc could make nondeterministic.
+
+There are already at least two other open bug reports wishing that
+git-annex somehow discover when a repo is on NFS and enable pidlock.
+
+
+
+(The second of those is really about something else, but it's been waiting
+on a fix being confirmed for 3 years, so the only useful part of it is I
+guess the last message in the thread, which discusses the difficulty of
+detecting NFS.)
+
+So I'm inclined to merge this bug report with the first of those.
+"""]]