Yikes ... FEP problem on an unsupported machine ...

[barmar@Think.COM (Barry Margolin)]

    Date: Wed, 11 Dec 1991 10:37 EST
    From: buff@pravda.cc.gatech.edu (Richard Billington)

    The 3600 I've been buiding my 8.1.1 world on is sick suddenly.

    Whenever I try to do any operation involving the newest boot.boot
    file in the FEP, I get a "header not FEPF" error message, indicating
    its looking for a FEP file system header, and finds garbage there.
    The operation can be either specific to this file, or just :Show
    Directory fep0:>*.*.*.  

    I'm at a loss as to how to fix this - si:fix-fep-file runs into the
    same error when I point it at fep0:>boot.boot.newest. Therefore, I
    assume there's some sort of fep file system directory which is what is
    corrupt, but I've no clue as to how to specify its pathname (seems
    like in really old versions of the file system editor (Rel 5?) this "file"
    showed up at the top, and if you opened it it contents were the fep
    directory listing).

The error message refers to a consistency check that the FEPFS software
performs.  Every FEP block that's either a file header, a data block in
a directory file, or a disk label has a four-character tag that
indicates what it is ("FEPF", "FEPD", and "LABL" respectively); when the
software is reading a file header, it checks that the tag matches the
expected type.  When the error occurs in the FEP, I suspect that it is
often because the block couldn't be read at all; it doesn't always seem
to check the status of the read, but it notices the error when the
resulting header is empty.

It sounds like the corruption is in the header of the file that contains
the root directory.  Although it doesn't show up in directory listings,
the name of the root directory is FEP0:>ROOT-DIRECTORY.DIR.1 (I got this
from (send #p"fep0:>" :directory-pathname-as-file)); however, when I try
to access this using normal file operations, it appears to be empty.

Does Show Directory show any info for other files in the directory, or
does it immediately get this error and abort?  If you're able to do a
"hello" successfully, then it's probably not the directory but just the
header of the boot.boot file.

A useful tool to determine precisely which block is bad is
SI:PRINT-FEP-FILESYSTEM.  It shows all file headers, directory entries,
and file maps.

SI:FIX-FEP-FILE can't deal with header or directory problems.  It only
knows how to fix problems in the data blocks of ordinary files.

Also, this may be just one symptom of a larger problem.  You may have
had a head crash or lost the formatting of a track.  You may want to run
"Test Disks" to see the extent of the damage.

The most obvious course of action is to try to reformat the disk.  If
that's not an option, you may need to write a tool that lets you
manually update some of the FEP filesystem structure.  Look at the
source to SI:PRINT-FEP-FILESYSTEM to learn the data structures and
appropriate operations.  Actually, I've sometimes done this by setting
breakpoints in SI:PRINT-FEP-FILESYSTEM, PRINTing and SETFing its buffer
arrays, and then manually calling SI:DISK-WRITE.

If the only thing you've lost is the root directory header, you may be
able to recreate it if you can mount the disk on another machine.  You
could write a program to search the disk for FEPD blocks, and then
construct a header that lists these blocks (I don't think the order of
blocks in a directory are significant).  The tricky part is that a
sequential scan of the disk will try to read bad blocks, so you'll have
to put plenty of error handling in.  Also, allocating the disk space for
the new directory file header will require checking and updating the
free space bitmap in the FREE-PAGES.FEP file (actually, you could
probably get away with just checking and not updating -- you'll probably
want to run SI:VERIFY-FEP-FILESYSTEM when you're done and it will fix
the inconsistency).  Then you'll have to update the disk label with the
new root-directory-dpn (you can use SI:EDIT-FEP-LABEL to do this).

On the other hand, if you've lost any ordinary file headers, there's no
redundancy there, and that file will be inaccessible.  If it's just
boot.boot you can probably live with it.  You can use
SI:PRINT-FEP-FILESYSTEM to discover the DPN, and then use
SI:FIX-FEP-BLOCK to move it to the bad block file.

                                                barmar