Re: System disks on Asimov

[Andy McFadden <fadden@fadden.com>]

Michael J. Mahon <mjmahon@aol.com> wrote:
>> It's probably possible to reduce it to a linear problem rather than an
>> exponential, but I'm not volunteering to examine all 8881 CRs to
>> determine if it's supposed to be an LF.
> 
> You make a very interesting point.
> 
> If there is internal redundancy of any useful kind in a ShrinkIt
> archive, then one could guess at the smaller number of LF/CR choices
> prior to the first checkable point, then progress to those between
> there and the next checkable point, etc.  This process could be part
> of an automatic recovery scheme.
> 
> Andy, is there any way of telling early when a decompression is
> running off the rails?

Sometimes.  ShrinkIt's LZW outputs codes that start at 9 bits and work
their way up to 12 bits.  It is possible to detect, for example, that a
given 9-bit code is being seen before it could have been emitted.  It
is not possible to tell with certainty that something is *right*, so some
mistakes can't be detected immediately.

Because it was designed to work on 5.25" disk tracks, the input is always
considered 4K at a time, though with LZW/2 the codes may not be reset
between blocks.  This can help detect problems, since blocks that don't
end right on 4K are bad.  This also leads to a problem: if a 4K chunk
doesn't compress with LZW, it is stored without compression.  The only
way to tell if it is correct is by the CRC, which for GSHK archives is
on the uncompressed data.

So I think it's safe to say that 2^8881 is an extreme upper bound, but
recovering an 800K floppy is still infeasible.

-- 
Send mail to fadden@fadden.com (Andy McFadden) - http://www.fadden.com/
Fight Internet Spam - http://spam.abuse.net/spam/ & http://spamcop.net/