Send in your Unix questions today! |
See additional Unix tips and tricks
I'm not exactly sure how this came about, but I recently found myself with a directory that didn't contain the standard "." and ".." directories that would have properly tied it into the file system. To fix the immediate problem, I moved the troublesome directory (using mv) and created a new one. When I tried to remove the (then renamed) directory, I found that I couldn't.
First, I tried the obvious. I tried removing the directory with rm, rmdir, rm -f and rm -rf. None of these commands worked for me.
# rm huh
rm: huh is a directory
# rmdir huh
rmdir: directory "huh": Directory not empty
# rm -f huh
rm: huh is a directory
# rm -rf huh
rm: Unable to remove directory huh: File exists
Except for the absence of "." and "..", the directory looked normal in a directory listing:
drwxr-xr-x 4 root root 1024 Sep 20 12:52 huh
Would I be able to remove it by referring to its inode number? I didn't think so, but I tried anyway.
# find . -inum 19640 -exec rm {} \;
rm: ./huh is a directory
# find . -inum 19640 -exec rm -rf {} \;
rm: ./huh is a directory
Clearly, I was running into the same underlying issue.
I could cd into the directory, though I clearly could not back out of it with "cd .." directory since .. didn't exist.
# cd huh
# ls -a
# touch junk
# ls
junk
# ls -l
total 0
-rw-r--r-- 1 root root 0 Sep 20 12:57 junk
# cd ..
..: does not exist
After creating an empty file, a subsequent rm -rf command removed the new file, but left the directory intact.
# rm -rf huh
rm: Unable to remove directory huh: File exists
# cd huh
# ls -al
total 0
# ls
# pwd
/var/huh
I began to wonder if I'd have to live with this anomaly, but then came up with an idea. If I moved the directory to another file system, the system would likely create it in its new location with all the proper attributes and maybe even remove all evidence of the odd directory from its initial location.
However, when I "moved" the directory, the botched original remained, even though the directory copy was normal in every way.
# mv huh /tmp
# ls
adm crash inet lp opt statmon
apache cron krb5 mail preserve tmp
apache2 dmi ld mysql run
appserver dt ldap news sadm
audit fm lib nfs saf
cache huh <== log nis sma_snmp
cc-ccr imq lost+found ntp spool
Of course, fsck will be able to repair this, I finally thought, and it certainly did, but it was more trouble than I anticipated. Notice in the output below that it noticed the missing files (e.g., MISSING '.').
# fsck -y /dev/md/dsk/d20
/dev/md/dsk/d20 IS CURRENTLY MOUNTED READ/WRITE.
CONTINUE? yes
** /dev/md/dsk/d20
** Currently Mounted on /var
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
DIRECTORY CORRUPTED I=19640 OWNER=root MODE=40777
SIZE=1024 MTIME=Sep 20 12:58 2006
DIR=/huh
SALVAGE? yes
MISSING '.' I=19640 OWNER=root MODE=40777
SIZE=1024 MTIME=Sep 20 12:58 2006
DIR=/huh
FIX? yes
MISSING '..' I=19640 OWNER=root MODE=40777
SIZE=1024 MTIME=Sep 20 12:58 2006
DIR=/huh
FIX? yes
** Phase 3a - Check Connectivity
UNREF DIR I=19653 OWNER=root MODE=40755
SIZE=512 MTIME=Sep 19 18:15 2006
RECONNECT? yes
DIR I=19653 CONNECTED. PARENT WAS I=19640
UNREF DIR I=19649 OWNER=root MODE=40755
SIZE=512 MTIME=Sep 19 18:14 2006
RECONNECT? yes
DIR I=19649 CONNECTED. PARENT WAS I=19640
** Phase 3b - Verify Shadows/ACLs
** Phase 4 - Check Reference Counts
LINK COUNT lost+found I=3 OWNER=root MODE=40700
SIZE=8192 MTIME=Sep 15 15:21 2006 COUNT 2 SHOULD BE 4
ADJUST? yes
** Phase 5 - Check Cylinder Groups
CORRECT BAD CG SUMMARIES? yes
CORRECTED SUMMARY FOR CG 0
CORRECTED SUMMARY FOR CG 1
FILE BITMAP WRONG
FIX? yes
FRAG BITMAP WRONG (CORRECTED)
CORRECTED SUMMARY FOR CG 5
FILESYSTEM MAY STILL BE INCONSISTENT.
18933 files, 99084 used, 1859431 free (11983 frags, 230931 blocks, 0.6% fragmentation)
***** FILE SYSTEM WAS MODIFIED *****
ORPHANED DIRECTORIES REATTACHED; DIR LINK COUNTS MAY NOT BE CORRECT.
***** FILE SYSTEM IS BAD *****
***** PLEASE RERUN FSCK *****
***** REBOOT NOW *****
As soon as the fsck was done, I rebooted and the file system was as it should have been, except for one small problem -- I still could not remove the directory, even though it now looked proper. Oops! Did that "REBOOT NOW" message mean after rerunning fsck?
# rmdir huh
rmdir: directory "huh": Directory not empty
# rm -rf huh
rm: Unable to remove directory huh: File exists
I then ran fsck again and rebooted:
# fsck -y /dev/md/dsk/d20
/dev/md/dsk/d20 IS CURRENTLY MOUNTED READ/WRITE.
CONTINUE? yes
** /dev/md/dsk/d20
** Currently Mounted on /var
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3a - Check Connectivity
** Phase 3b - Verify Shadows/ACLs
** Phase 4 - Check Reference Counts
LINK COUNT DIR I=19640 OWNER=root MODE=40777
SIZE=1024 MTIME=Sep 20 12:58 2006 COUNT 4 SHOULD BE 2
ADJUST? yes
** Phase 5 - Check Cylinder Groups
CORRECT BAD CG SUMMARIES? yes
CORRECTED SUMMARY FOR CG 0
CORRECTED SUMMARY FOR CG 1
CORRECTED SUMMARY FOR CG 5
FILESYSTEM MAY STILL BE INCONSISTENT.
18933 files, 99109 used, 1859406 free (11990 frags, 230927 blocks, 0.6% fragmen
ation)
***** FILE SYSTEM WAS MODIFIED *****
***** FILE SYSTEM IS BAD *****
After another fsck -y and a reboot, the file system was intact and I was able to remove the strange directory without a problem. Interesting, this was a problem that I hadn't encountered before.
