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