edward@Edvax.UUCP (Edward Wilkinson) (11/16/87)
Sometimes, when I do a `rm -rf dir', every so often rm complains about a `directory not empty' error somewhere down the hierarchy. This propagates to the higher levels & leaves an empty directory structure behind. Another `rm -rf dir' results in the same, even when executed as super-user. I once tried using unlink(2) with less than best results: as me, it didn't work, while as superuser, the following fsck fell over. We then had to do a restore, which left us with the dud `empty' directory again. Does anyone know what I'm doing wrong? We run Ultrix 1.2 on a Vax 750 if it's any use. Any ideas would be most gratefully received. -- Ed Wilkinson ...!uunet!vuwcomp!edward or edward@comp.vuw.ac.nz p.s. do NOT send to Edvax - it probably won't get there. My vuwcomp guest account is easily accessible and reliable.
dlm@cuuxb.ATT.COM (Dennis L. Mumaugh) (12/10/87)
In article <125@Edvax.UUCP> edward@comp.vuw.ac.nz (Edward Wilkinson) writes: >Sometimes, when I do a `rm -rf dir', every so often rm complains about >a `directory not empty' error somewhere down the hierarchy. This >propagates to the higher levels & leaves an empty directory structure >behind. Another `rm -rf dir' results in the same, even when executed >as super-user. I once tried using unlink(2) with less than best >results: as me, it didn't work, while as superuser, the following fsck >fell over. We then had to do a restore, which left us with the dud >`empty' directory again. > >Does anyone know what I'm doing wrong? We run Ultrix 1.2 on a Vax 750 >if it's any use. Any ideas would be most gratefully received. > I haven't seen any response posted and since this is from Down Under the person may not get any other answer so here goes: One of the more nasty habits of programs is to use a so-called dot file. This is a file beginning with a period. The purpose of these files is to save information and at the same time suppress any evidence of their existence. This is because of the fact there are ALWAYS (or almost always) two such files in any directory ("." and ".."). To avoid always see those files with an ls command and using their name in a global (as in rm *) the software in the shell and ls ignore all file names beginning with period. (Ls -la will change this). The problem with the dot files is that when it comes time to remove the directory (with rmdir or rm -rf) it appears the irectory is empty but it really isn't and thus the program balks. Solution: cd to the directory that can't be removed and do an ls -la You ought to see some files. Then do a rm -f .* This is okay since rm won't remove directories. Then continue as previously. Why does rm -rf bitch? Because it does a fork and then execs the command rm -rf * (which won't pick up the dot files). After which it will do an rmdir * (to cleanup the sub-directories). -- =Dennis L. Mumaugh Lisle, IL ...!{attunix,ihnp4,cbosgd,lll-crg}!cuuxb!dlm
sdejarne@polyslo.UUCP (Steve DeJarnett) (12/14/87)
I had a problem like this on an HP-9000 system recently. The problem was that there was a file in the directory that was undeletable. rm -rf didn't catch it, but things like find(1) and ls(1) did. fsck(1m) didn't notice it, so basically I was out of luck. What I ended up doing was emptying the directory, then doing an "od -dc ." which showed me the files in the directory and their corresponding inode numbers. Then I used fsdb(1m) to change the type of the inode of the file that couldn't be deleted to a type that signalled that the inode was unused. fsck(1m) then caught it and removed it (when I told it to). I'm not sure if that's you're problem, but it's worth a try. BE CAREFUL USING fsdb(1m)!!!!!!! Our version presumed that you knew what you were doing, so it didn't check anything that you did. It also did it in real-time (no undo features). Also, in response to another follow-up posted by someone at AT&T, I think that "rm -rf" should get rid of any . files in the directory. That is kind of what the purpose of "rm -rf" is (i.e. "Get rid of every file in all directories below the named one, including the named one"). The only problem I ever ran into with that was not having write permissions on some of the subdirectories below the one being removed. If you don't have write permission on the directory, rm won't remove it, and therefore, "rm -rf" will bomb when it sees that there is still an entry (a directory that isn't empty, or that can't be removed due to not having write permission) along the path. Make sure your permissions are right (although, if you are root, it shouldn't matter). Good luck. ------------------------------------------------------------------------------- | Steve DeJarnett | ...!ihnp4!csun!polyslo!sdejarne | | Computer Systems Lab | ...!{csustan,csun,sdsu}!polyslo!sdejarne | | Cal Poly State Univ | ...!ucbvax!voder!polyslo!sdejarne | | San Luis Obispo, CA 93407 | | ------------------------------------------------------------------------------- #include <std_disclaimer.h>