Deal with NFS problem that caused a failure to remove a directory when removing content from the annex.

I was able to reproduce this on linux using the kernel's nfs server and
mounting localhost:/. Determined that removing the directory fails when
the just-deleted file in it was locked. Considered dropping the lock
before removing the directory, but this would complicate parts of the code
that should not need to worry about locking. So instead, ignore the failure
to remove the directory in this case.

While I was at it, made it attempt to remove both levels of hash
directories, in case they're empty.

1 files changed, 14 insertions, 0 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
index aa0c3cc29..761ee5b25 100644
--- 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
@@ -43,3 +43,17 @@ I'm on an nfs mounted filesystem (some netapp somewhere).  This is repeatable, e
 
 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]]