Xref: utzoo comp.unix.aix:404 comp.sys.ibm.pc.rt:1290
Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!ibmpa!bass.tcspa.ibm.com!webb
From: webb@bass.tcspa.ibm.com (Bill Webb)
Newsgroups: comp.unix.aix,comp.sys.ibm.pc.rt
Subject: Re: rm: file exists.   filesystem problem?
Message-ID: <3513@ibmpa.UUCP>
Date: 8 Jan 90 20:43:16 GMT
References: <82@blender.UUCP>
Sender: news@ibmpa.UUCP
Organization: IBM AWD Paloalto
Lines: 47

> '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