[Info-vax] Odd BACKUP error: unsupported file structure !

[hb]

On Nov 11, 3:46 am, JF Mezei <jfmezei.spam... at vaxination.ca> wrote:
> So I decided to do an ana/disk/repair to get the strange error messages
> that don't seem to go away:
>
> -ANALDISK-I-BAD_FIDNUM, unexpected FID_NUM or FID_NMX field
> -ANALDISK-I-INVHEADER_BUSY, invalid file header marked "busy"
>         in index file bitmap
> %ANALDISK-W-BADHEADER, file (4479,639,0)
>         invalid file header
Looks like a different file, in the OP the FID was (58136,1,0); looks
like a different problem.
The secondary message BAD_FIDNUM is for a different file as well. Were
there other seconday messages and messages for FID (58136,1,0)?

If the file structure is invalid analyze/disk should give you:

%ANALDISK-W-BADHEADER, file (16,3,0)
        invalid file header
-ANALDISK-I-BAD_STRUC_LEVEL, STRUCLEV field is bad
-ANALDISK-I-INVHEADER_BUSY, invalid file header marked "busy"
        in index file bitmap

You may see subsequent messages like
%ANALDISK-W-ALLOCCLR, blocks incorrectly marked allocated
        LBN 45 to 51, RVN 1
%ANALDISK-W-BADDIRENT, invalid file identification in directory entry
        [000000]JUNK.DAT;1
-ANALDISK-I-BAD_DIRHEADER, no valid file header for directory
%ANALDISK-W-FREESPADRIFT, free block count of 48 is incorrect (RVN 1);
        the correct value is 55

Yes, the manipulated file header is for JUNK.DAT;1 which has FID
(16,3,0).

On the other hand, dump/header is not designed to show you anything in
case of
an invalid file structure:
$ dump/header lda16:[000000]junk.dat/bl=co=0
%DUMP-E-OPENIN, error opening LDA16:[000000]JUNK.DAT;1 as input
-RMS-E-ACC, ACP file access failed
-SYSTEM-W-FILESTRUCT, unsupported file structure level
$
and
$ dump/header lda16:/id=16
%DUMP-E-BADHEADER, File ID references invalid or non-ODS-2 file header
$

The SYSTEM-W-FILESTRUCT secondary error message looks like the one you
had with backup/image. It looks like backup tried to read the file
header - probably the same way as dump/header <file_spec> - and it
failed.

> Any hints on what this really means ? Interesting that backup only found
> a couple of "invalid structure level files", but ana/disk finds a few
> hundred of the above messages. It does not seem to repair them.

Aha, the BAD_STRUC_LEVEL for the (58136,1,0) may be in the few
hundreds. But in another post you showed that dump/header worked on
that file. So there is very likely a different problem - maybe with
the disk.

Obviously anal/disk does not repair such errors. It assumes that the
file header is corrupt. It doesn't seem to try whether the correct
structure level would make it a valid header. I don't know much about
DFU, maybe it can do that. But I'm not yet convinced that "corrupt
headers" are the real problem.

> My hope is that with a reboot (and a volume rebuild that takes 45
> minutes), I'll be able to do a proper backup and then reinitialise the
> disk with a smaller indexf.sys and perhaps it will work fine.

I don't understand what you are going to do. If the headers are
corrupt in INDEXF.SYS, a reboot and a rebuild will not change anything.