herb@blender.UUCP (Herb Peyerl) (01/02/90)
I've been having a fair number of problems with my release of BNews
on my PC-RT 6150-25 running AIX 2.2.1... This morning I did an
expire -e 0 and it basically didn't find any of the 32000 blocks of
news that was sitting there... So, fine, this has happened before.. I
ran my little script that deletes the current news structure and recreates
it with the proper permissions and owners... Except that in the
'rm -r' portion of our program, I got 4 "rm: file exists" messages. I
dug into the filesystem a bit and found :
# du -a
4 ./comp/sys
8 ./comp
4 ./sci/med
8 ./sci
24 .
# rm -r comp/sys
rmdir: file exists
# cd comp/sys
# ls -al
total 8
drwxrwxrwx 3 news news 592 Jan 7 12:52 .
drwxrwxr-- 3 news news 800 Jan 7 12:54 ..
# cd ..
# rm -ri *
directory sys: y
sys: y
rmdir: file exists
# rm sys
rm: sys directory
#
Anyone have any ideas? I often run out of disk space on that particular
filesystem and it occasionally gets screwed up after BNews has had it's
way with it... I end up recreating the filesystem once every couple of
months... Should this be the way a unix machine should work?
--
---------------------------------------------------------------------
UUCP: herb@blender.UUCP || ...calgary!xenlink!blender!{herb||root}
ICBM: 51 03 N / 114 05 W || Apollo Sys_admin, Novatel Communications
"The other day, I...... No wait..... That wasn't me!" <Steven Wright>karish@forel.stanford.edu (Chuck Karish) (01/09/90)
In article <82@blender.UUCP> herb@blender.UUCP (Herb Peyerl) wrote: >I've been having a fair number of problems with my release of BNews >on my PC-RT 6150-25 running AIX 2.2.1... ># rm -r comp/sys >rmdir: file exists ># cd comp/sys ># ls -al >total 8 >drwxrwxrwx 3 news news 592 Jan 7 12:52 . >drwxrwxr-- 3 news news 800 Jan 7 12:54 .. ># cd .. ># rm -ri * >directory sys: y >sys: y >rmdir: file exists >Anyone have any ideas? The link count for sys should be 2, not 3. Bnews must have used the "link" command with superuser privileges to make an extra link to comp/sys. Use "unlink" on the directory, and you'll be able to remove its parent. It might be interesting to use "ls -i" to find out where the other link is. Use "unlink" carefully, and run "fsck" afterwards. It's easy to corrupt your filesystem with this command. It's possible on some systems to link a directory to its parent. This can put fsck into an infinite loop, a most undesirable state of affairs. >Should this be the way a unix machine should work? It's not the way a well-behaved application should work. If Bnews created the extra link without using "link", no, this is not the way a UNIX machine should work. Chuck Karish karish@mindcraft.com (415) 323-9000 karish@forel.stanford.edu
webb@bass.tcspa.ibm.com (Bill Webb) (01/09/90)
> 'rm -r' portion of our program, I got 4 "rm: file exists" messages. I > > # du -a > 4 ./comp/sys > 8 ./comp > 4 ./sci/med > 8 ./sci > 24 . > # rm -r comp/sys > rmdir: file exists > # cd comp/sys > # ls -al > total 8 > drwxrwxrwx 3 news news 592 Jan 7 12:52 . > drwxrwxr-- 3 news news 800 Jan 7 12:54 .. > ... > Anyone have any ideas? ... > UUCP: herb@blender.UUCP || ...calgary!xenlink!blender!{herb||root} The clue is that the link count on "." in comp/sys is 3. Either your filesystem is damaged or there is another link to that directory somewhere else in the filesystem. rmdir is refusing to remove the directory because the link count is > 2, which normally only happens if there are files in the directory. If you haven't run fsck I suggest that you do so (I'll presume that you already have). I suggest that you use a find command to locate the link (it will have the same inode number). You can then use the "unlink" command (as root) to remove the extra link. Note that you can recreate the problem by doing the following (which I did mkdir foo link foo bar ls -la foo then when you try a rm -r foo I saw the same messages that you did. Doing an "unlink bar" then allowed me to have "rm -r foo" work properly. Note you should be very, very, careful when using "link" and "unlink" as root as they can damage the normal filesystem structure. This can also happen when you run programs as root that might issue the corresponding system calls without checking to make sure that what they are linking or unlinking isn't a directory. This is presumably how the filesystem got into the state that it is currently in. If at all possible you should run such programs without root privilege, making them setuid or setgid as required to some other id (e.g. "news"). ---------------------------------------------------------------- The above views are my own, not necessarily those of my employer. Bill Webb (IBM AWD Palo Alto), (415) 855-4457. UUCP: ...!uunet!ibmsupt!webb