macOS: rm: cannot remove 'foo': Directory not empty
I recently ran into an issue where I couldn't delete an apparently empty directory from the plain view of a directory mounted with gocryptfs.
Trying to remove the directory resulted in an error: rm: cannot remove 'foo': Directory not empty.
I figured out that the problem was that the real/encrypted directory had some extra files in it, created by macOS at some point in the past, and these were preventing gocryptfs from properly deleting the underlying encrypted directory.
For example (crypt is the encrypted directory; plain is the view mounted by gocryptfs):
crypt/
asdfghjkl/
._lkjsdlkjflskjflkj
gocryptfs.diriv
gocryptfs.conf
gocryptfs.diriv
plain/
foo/
Trying to rm -r plain/foo produces an error since the underlying encrypted directory is not empty.
._lkjsdlkjflskjflkj and any similarly named files (starting with ._) in the encrypted directory are "resource forks" created by macOS. They have something to do with storing thumbnail images or extended file attributes. A file called asdf.txt might have an associated resource fork called ._asdf.txt; the presence of ._lkjsdlkjflskjflkj indicates that there used to be a file in the encrypted directory called lkjsdlkjflskjflkj, which would have been the encrypted version of some now-deleted file in the plain view.
I'm guessing that at some point when I opened the encrypted directory on a mac, macOS created some ._ files. When I later, via gocryptfs (possibly from another, non-macOS system), deleted the corresponding regular files, the ._ files were not cleaned up. This made it impossible for gocryptfs to delete the directories.
I was able to delete my "empty" directory from the decrypted view after first cleaning up the ._-prefixed files in the encrypted directory.
I guess gocryptfs could clean up orphaned resource fork files when it encounters them, but that doesn't really seem like its responsibility. So this issue can probably be closed-- I've logged it more as an FYI and so that anybody who runs into the same problem in the future can find it.