For the benefit of the readers:
rm -rf in such a case! It can create problems somewhere else in case it happen to be a network share! You have been warned!
In nearly all cases, if a
directory seems to be empty, use
rmdir directory or perhaps
sudo rmdir directory. Do not use
del under Windows). If this does not work, you need to find out, what blocks this request, fix that and then retry the
Please note that I do not know OS-X, but I think things there are very similar to the Unix/BSD behavior.
It is very likely that the directory in question was just a mount point (from the encfs) or residing on a mount point which became readonly or stuck in some improper state (which prevented the directory to be removed). If you now force removal of the directory, very bad things can happen.
In the good case the directory really was empty, so removing it (destroying the mount etc.) did no further harm. In the bad case it wasn't empty, just appeared to be, which means, you trashed something which you perhaps did not want to kill. This all depends on the mount type, which drivers are in use etc. pp.
If things are implemented reasonably well, normally nothing bad should happen. However this is not the normal case. Things are in a weird state already, which means: Something is wrong, so better do not try to mix it up even further! If something is cracked, any wrong touch might break it.
For example, if you hit a race condition on a network share, it might be that your
rm -rf removes data which is just copied to the share by somebody else.
rmdir is guaranteed to never do harm, besides removing really empty directories. This is even true on NFS, because NFS only guarantees truly atomic behavior on
rmdir, but nowhere else.
You can detect a mountpoint using the tool
mountpoint directory. Alternatively look into the output of
mount and try to spot your mounts there. But beware, at least under Linux this might lie. Using the
mountpoint utility more reliable but less convenient.
In that case you found the mountpoint, you can unmount it and then remove the directory, this is following sequence:
If needed use
sudo, as usual.
Network shares might deny
rmdir (and anything else) due to access rights.
Defective filesystems may deny
rmdir, depending on the fail strategy. Perhaps you will see a reasonable message in that case, perhaps not.
Under Linux (and probably any modern OS) you can also restrict access using different means (like mounting something readonly, capabilities like in SeLinux, etc.). This then means you do not see that it is a mountpoint, and you do not see anything wrong, but it just does not work. In that case you need to look for some other reason and it can be very deeply buried in the OS. It depends on the tool if you see some reasonable error message. Also perhaps have a look into the syslog/kernel-log like
dmesg under Linux (sorry, I do not know the OS-X equivalent).
Note that mandatory file locking may be a source, too. While this is normal on Windows, usually it is not the normal case Unix and I never heared it for directories. Mandatory file locks are covered by POSIX, but they are optional.
Quite often in such cases, the directory in question resides on a different filesystem than which you thought. You can find out which, with the command
df directory (I think this is the same under OS-X).
You can inspect deeper with tools like
statfs on the directory. However these are a bit low level for normal people, and quite often such tools are well hidden from normal users.
Directories can have files with funny names. Like a file which immediatelty erases the terminal output, so it looks like it isn't there. Try something like
ls -al | less or use something like MidnightCommander
There are trainload of other possibilites, including bugs, haxors, aliens, or perhaps more exotic things like fairies. But usually it is not wise to start looking there, instead first try to find the error at your side, because "errare humanum est".
rmdirit -- but it often is the cause why one cannot unmount a volume).