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