testing for corruption

[Kenneth Brody]

Quoting Brian K. White (Wed, 6 Feb 2008 02:47:09 -0500):

[...]
> Why can't a record be marked for deletion and have old data in it?
> How do you know if the 20byte header is wrong or the data is wrong?
[...]
> You *may* detect that the data doesn't line up with the map, *if* you happen
> to be lucky and the file uses any edits that garantee certain minimum data
> must exist, but, even in that lucky case, how do you know the which is
> corrupt, the data, or the map? The application author can say that. No one
> else can. They know what they wanted.  Which btw, is no garantee that's what
[...]

There aren't too many things guaranteed within the key file (assuming that
there is no "corruption", by whatever definition you want to use):

1 - The first byte will always be 0, 1, or 2.
2 - The second byte will always be 0.
3 - Bytes 17 to 20 (assuming 1-relative) will always be 0.

Aside from that, you can't really guarantee much.

4a - If the first byte is 0, then you could "sanity check" the two 32-bit
      values representing the freechain pointers.
4b - If the first byte is 1, then you could "sanity check" the three 16-bit
      values representing @CD/@UD/@BD.

There are no specific guarantees about what you will find in the record
itself, beyond being "valid" based on the edits.  (ie: unless you have an
edit which forbids it, all 256 values for a character can occur.)

Of course, as Brian said -- does this mean the key file is corrupt, or does
it mean that it simply doesn't match the map?  And if it doesn't match the
map, which one is wrong?

-- 
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com