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