1 files changed, 0 insertions, 59 deletions
diff --git a/doc/bugs/nfs_mounted_repo_results_in_errors_on_drop_move.mdwn b/doc/bugs/nfs_mounted_repo_results_in_errors_on_drop_move.mdwn
deleted file mode 100644
index 761ee5b25..000000000
--- a/doc/bugs/nfs_mounted_repo_results_in_errors_on_drop_move.mdwn
+++ /dev/null
@@ -1,59 +0,0 @@
-I'm on an nfs mounted filesystem (some netapp somewhere).  This is repeatable, every time.
-
-    git init repo; cd repo;
-    git annex init repo
-    truncate -s 20M big
-    git annex add big
-    git commit -m "annexed file"
-    cd ..
-    git clone repo repo_copy
-    cd repo_copy;
-    git annex get .
-    git annex whereis big
-
-    #whereis big (2 copies) 
-    #   	9310b242-6021-4621-8cef-4548a00907ff -- here
-    #   	b3526e4d-38d7-4781-a9c3-436007899f1b -- origin (repo)
-    #ok
-
-    git annex drop big
-
-    #git-annex: /nfspath/repo_copy/.git/annex/objects/fM/4k/SHA1-s20971520--9674344c90c2f0646f0b78026e127c9b86e3ad77: removeDirectory: unsatisified constraints (Directory not empty)
-    #failed
-    #git-annex: drop: 1 failed
-
-    git annex drop big  # no error second time, I suspect nfs has caught up by now.
-    git annex fsck      # Doesn't know that the second drop succeeded.
-
-    #fsck big (fixing location log) 
-    #  ** Based on the location log, big
-    #  ** was expected to be present, but its content is missing.
-    #failed
-    #git-annex: fsck: 1 failed
-
-    git annex fsck
-
-    #fsck big ok
-
-    git annex whereis big
-
-    #whereis big (1 copy) 
-    #  	b3526e4d-38d7-4781-a9c3-436007899f1b -- origin (repo)
-    #ok
-
-I suspect git-annex is just too fast and optimistic for big slow nfs directories.
-
-> git-annex locks files while it is operating on their content
-> to avoid race conditions with other git-annex processes. 
-> Quite likely this problem (which I can reproduce) is due to
-> NFS having bad (non-POSIX) locking semantics. 
-> 
-> Probably the
-> lock is represented on the NFS server as some form of lock file
-> next to the file being locked, and so when that file is deleted, with
-> the lock still held, the directory, which should then be empty, still
-> contains this lock file.
-> 
-> So, this can be worked around by it not failing when the directory
-> unexpectedly cannot be removed. I've made that change. [[done]]
-> --[[Joey]]