For the benefit of the readers:
Beware 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 rm
(or del
under Windows). If this does not work, you need to find out, what blocks this request, fix that and then retry the rmdir
.
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.
However 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 mkdir
and rmdir
, but nowhere else.
FYI:
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:
umount directory
rmdir directory
If needed use sudo
, as usual.
Notes:
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 stat
or 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 mc
.
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".
2Do you have any other shell open within this directory, or an app running just using it? The term "is in use" could also mean that (though I never experienced not being able to
rmdir
it -- but it often is the cause why one cannot unmount a volume). – Izzy – 2012-08-27T22:44:05.730Not at the time those particular commands had been issued. I had done a complete reboot just prior to that. – Ben Hocking – 2012-08-28T13:03:30.177
I sometimes have the same problem with EncFS and so far I have no idea how to solve this. Anything new? – Martin Preusse – 2012-10-04T21:34:27.943
@emempe: What I finally ended up doing was deleting the folder in the encrypted space, using the last modified timestamp as my identifier. (Which can be dangerous.) If I come up with a better solution, I'll let you know. – Ben Hocking – 2012-10-04T21:42:02.590
@BenHocking: I do that too. Happens rarely for me so I'm fine with this. Still, I don't like the feeling that my EncFS got corrupted somehow ... ;) My EncFS is in a Dropbox, maybe some connection? – Martin Preusse – 2012-10-04T21:49:16.667