overstre@dca-eur.ARPA (05/10/84)
From: Herbert Overstreet <overstre@dca-eur.ARPA> I took over this host in March and have been trying to get rid of a bad directory which was created in November. The directory cat/file string is '/u17/lost+found/#005628'. I position myself at the directory 'lost+found' and then enter "rm -rf *562*" just encase there are any unprintable characters. The response is 'rmdir: Cannot remove "#005628". No such file or directory.' Do you have any suggestions on how to clean this out. Thanks: Herb Overstreet (DCA-EUR Administrator)
bob@SU-SHASTA.ARPA (05/10/84)
The standard way to remove a bad directory is: 1. Take the system down to single-user mode (killing all user processes if System III/V). 2. Attempt to recover files from the bad directory by LSing it and moving the files elsewhere. If corruption is severe this may not be possible. Also, there may not be anything to move. 3. Determine the inode of the directory. If the directory was restored by fsck then the name (less any "#") is the inode number. A "ls -li" on the parent directory will list the inode number at the start of the line. 4. Determine the device name of the file system. 5. As root give the command "clri <FSdevice> <inode number>". This zaps the inode into oblivion. 6. Run "sync". 7. Run "fsck" on the file system. This works on Version 7, System III/V, and BSD*. Bob Toxen Silicon Graphics ucbvax!olympus!bob
gwyn@BRL-VLD.ARPA (05/11/84)
From: Doug Gwyn (VLD/VMB) <gwyn@BRL-VLD.ARPA> rm -ri . works pretty well when one cannot seem to type the correct name of a file to be removed. This way, rm looks up the names directly from the directory and is bound to hit the one you're after eventually.
barto@celerity.UUCP (05/13/84)
I hope you are running 4.2....
We here at celerity had just the same problem. I 'fixed' it by
doing an 'clri' on the inode. By then re-running 'fsck' it removed
the 'unreferenced' file.
This was the most bizarre thing that has happened since we put
4.2 up. (With the execption of the sendmail daemon getting attached
to at tty port....)
--
barto
(david barto)
uucp : {decvax!ucbvax || ihnp4 || philabs}!sdcsvax!celerity!barto
uucp : akgua!celerity!barto
arpa : sdcsvax!celerity!barto@nosc
Tele : (619) 566 0416faustus@ucbvax.UUCP (Wayne Christopher) (05/15/84)
What do you suppose would happen if you went and inserted a '/' into a filename (by adb'ing /dev/???, for instance). Anybody want to try it out and see if fsck can handle it? Wayne
jab@uokvax.UUCP (05/21/84)
#R:sri-arpa:-63500:uokvax:6200027:37777777600:1329 uokvax!jab May 20 20:57:00 1984 /***** uokvax:net.unix-wizar / sri-arpa!ARPA / 7:13 pm May 15, 1984 */ The standard way to remove a bad directory is: 1. Take the system down to single-user mode (killing all user processes if System III/V). 2. Attempt to recover files from the bad directory by LSing it and moving the files elsewhere. If corruption is severe this may not be possible. Also, there may not be anything to move. 3. Determine the inode of the directory. If the directory was restored by fsck then the name (less any "#") is the inode number. A "ls -li" on the parent directory will list the inode number at the start of the line. 4. Determine the device name of the file system. 5. As root give the command "clri <FSdevice> <inode number>". This zaps the inode into oblivion. 6. Run "sync". 7. Run "fsck" on the file system. This works on Version 7, System III/V, and BSD*. Bob Toxen Silicon Graphics ucbvax!olympus!bob /* ---------- */ Something that may be obvious to some but not to others is that between steps two and three, you MUST unmount the filesystem you're planning to modify if there is any chance at all of the inode in question being incore. The reason for this is that if it's in the inode table that the kernel keeps, the "sync" in step 6 could very well undo what step 5 helps. Jeff Bowles Lisle, IL