Dangling inode problem

Bent Hagemark bh at sgi.com
Wed Dec 5 14:23:29 AEST 1990


In article <srp.660086900 at babar.mmwb.ucsf.edu> srp at babar.mmwb.ucsf.edu (Scott R. Presnell) writes:
>dhinds at 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 at cgl.ucsf.edu
>University of California			UUCP: ...ucbvax!ucsfcgl!srp
>San Francisco, CA. 94143-0446			Bitnet: srp at 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



More information about the Comp.sys.sgi mailing list