Return to BSD News archive
Path: sserve!manuel.anu.edu.au!munnari.oz.au!hp9000.csc.cuhk.hk!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!wupost!uunet!olivea!charnel!rat!ucselx!network.ucsd.edu!sdcc12!icogsci5!cg18fbi From: cg18fbi@icogsci5.ucsd.edu (Richard Dante) Newsgroups: comp.unix.bsd Subject: Re: corrupted directory, can't remove Keywords: help Message-ID: <42120@sdcc12.ucsd.edu> Date: 7 Dec 92 10:09:32 GMT References: <carlp.723695363@frigg> <1fus1pINNqqe@charnel.ecst.csuchico.edu> Sender: news@sdcc12.ucsd.edu Organization: University of California, San Diego Lines: 39 Nntp-Posting-Host: icogsci5.ucsd.edu In article <1fus1pINNqqe@charnel.ecst.csuchico.edu> fish@ecst.csuchico.edu (Kevin Haddock) writes: >In article <carlp.723695363@frigg> carlp@frigg.isc-br.com (Carl Paukstis) writes: >>This is the second time it's happened. Some directory got corrupted for >>bad reasons (me fooling around with my hardware config; this time I >>added RAM over 16Mb, which I thought might be foolish...). >>My experience is all with SYSV; someone suggested "clri()", but I don't >>see any such under 386BSD. The last time this happened, I was about to >>clear and rebuild my disk anyway, but I'd prefer not to do that again. > >I had the same problem. Basically I was not able to find any solution >other than rebuilding the file system. What I WAS able to do was to >prevent it from happening again (at least so far). What I believe was >responsible was the behavior corrected by patch00038 (errors not seen >when reading raw wd device). > >Best-o-luck, >-Kevin. When you get a corrupted file or directory that rm and fsck can't cope with you should use clri to banish them (Hopefully the file wasn't too important. If it is, I suggest you cat what you can to another file). Unfortunately there is no manpage for clri but the format for the command is simple enough: /sbin/clri <filesystem> <inode>. For <filesystem> use the raw device file for the hard drive in question. For example /dev/rhd0a for a standard (non scsi) drive. If you're not sure what the device for the hard drive is then watch for it next time you run fsck. To find out the troubled inode number, ls -i will print out inodes for files. Again, fsck will tell you the inode number too. The problem is that fsck just can't blast the really pesky inodes (dman thing shouldn't ask to salvage what it can't if you ask me) Let's say your drive is /dev/rhd0a and the inode to the troubled item is 12345 you would type "clri /dev/rhd0a 12345" and then sync and reboot. Fsck will now up the blasted fragments. I pity all who have rebuilt their filesystems for not knowing this, there really should be a manpage. Rick Dante