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. +"""]]