news@wcom.UUCP (News Administrator) (03/28/85)
My IBM PC/AT Xenix (System III) system went wierd last nite, resulting in the /usr/bin directory being transmuted into an unreachable directory. What happened was that the `i' in `bin' was turned into a null, and no matter what I tried to do, the system kept complaining that 'b' was non-existant. I ended up remaking the filesystem from a backup. Was that the only solution, or does someone else have a better way? Jim Scardelis
ignatz@aicchi.UUCP (Ihnat) (03/29/85)
Jim wrote that his IBM PC/AT went wonka, put a very anti-social null in place of the 'i' in the name of his /usr/bin directory name, and asked if there was a better way to recover than to reformat & recover. Yep, but you ain'ta gonna like it. ADB. Yes, folks, just adb that raw hard disk device (unless you're lucky enough to have a ported version of 'fsdb'...) Using adb, you can do everything from twiddle the superblock to fiddle the directory. Only trouble is, if you're not very comfortable with the file system structure, then this could be more painful than the recovery. (It isn't for me, but Altos diskette drives are notoriously slow) It really does help to know the block breakdown scheme for the driver (i.e., blk => cyl/head/sector), although you can still do it without that. This is *really* getting dirty, -- Dave Ihnat Analysts International Corporation (312) 882-4673 ihnp4!aicchi!ignatz
chris@umcp-cs.UUCP (Chris Torek) (03/29/85)
Adb (or---if you're lucky enough to have one---a file system scribble
tool program) can correct mucked up directory names.
However, (and I'm not sure if works for System n, where 3 <= n <= 5),
there is a better way: if /usr is corrupted such that /usr/bin is now
/usr/b^@n, then "ln /usr/b" to "/usr/bin". This works iff your namei
code doesn't compare the entire name, including all trailing nulls.
Unfortunately, most do.
As a third alternative, you can always "mkdir /usr/bin" and restore
only the files that go there (assuming you have plenty of disk space),
then remove the "/usr/b^@n" later.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@marylandchris@umcp-cs.UUCP (Chris Torek) (03/29/85)
On rereading my reply, I notice I forgot the most important piece of
information: how to use adb to fix directories.
Well, it ain't easy. If you need to fix the /usr directory, then first
you have to find out the file system name and inode number of /usr.
Then you run "adb -w /dev/rxxns" (where xx is the disk, n is the unit
number, and s is the partition name) and take a look at the inode for
/usr (the method for finding this is different from Unix to Unix, but
for most non-4.2's is a matter of adding an offset to the result of
multiplying the inode number the size of a disk inode. In 4.2 you'd
have to find the right cylinder group, which is another matter....)
Anyway, dump out that inode (in whatever format it's in; look at
<sys/inode.h>) and somewhere in there will be the list of blocks that
/usr occupies. Track those down and you'll find a bunch of "struct
direct" entries (hopefully) which represent the contents of /usr. In
there will be the "b^@n" entry (or other corrupted entry), which is
then easily patched.
----------
Oh yes, before I forget (I did last time): there's a fourth alternative
that may be easier than any of the others. If you "clri" the inode for
/usr, fsck will pick up all the directories that used to be under it
and deposit them in /usr/lost+found. Then it's just a matter of
figuring out which directory is which, and "mv"ing them back into
place.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@maryland