mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

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

Browse source 
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.
This commit is contained in:
Joey Hess 2012-02-24 16:30:47 -04:00
parent c9b48520cc
commit bd66f962d3
3 changed files with 39 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

14
doc/bugs/nfs_mounted_repo_results_in_errors_on_drop_move.mdwn
View file

@ -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]]