Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ames!sgi!shinobu!odin!bh
From: bh@sgi.com (Bent Hagemark)
Newsgroups: comp.sys.sgi
Subject: Re: Dangling inode problem
Message-ID: <1990Dec5.032329.5531@odin.corp.sgi.com>
Date: 5 Dec 90 03:23:29 GMT
References: <1990Dec1.194910.9878@portia.Stanford.EDU> <srp.660086900@babar.mmwb.ucsf.edu>
Sender: news@odin.corp.sgi.com (Net News)
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 33

In article <srp.660086900@babar.mmwb.ucsf.edu> srp@babar.mmwb.ucsf.edu (Scott R. Presnell) writes:
>dhinds@portia.Stanford.EDU (David Hinds) writes:
>
>>few days ago to restart it, the resulting fsck activity produced a directory
>>entry in /lost+found that does not point to anything.  A file called '000258'
>>shows up if I do 'ls', but 'ls -l' complains that the file does not exist.
>>I have done everything I could think of to get rid of this dangling entry -
>>'rm', 'unlink', etc. all fail.  I can't create another file of the same name
>
>[...]
>
>>How do I get rid of this dang thing?
>
>I had the exact same thing happen to me.  While not an optimal fix, another
>reboot (and implicit fsck) cleared away the reference.
>
>	- Scott
>--
>Scott Presnell				        +1 (415) 476-9890
>Pharm. Chem., S-926				Internet: srp@cgl.ucsf.edu
>University of California			UUCP: ...ucbvax!ucsfcgl!srp
>San Francisco, CA. 94143-0446			Bitnet: srp@ucsfcgl.bitnet


Yes, fsck properly clears the reference, and yes nothing else can.
The problem is that the directory entry refers to an inode which
is deallocated.  The kernel EFS code can't even namei() this name much
less unlink(2), open(2)...

The bug which creates such errant directory entries has been fixed and
is available in The Next Release.

Bent