Re: New stuff - NuLib2, HardPressed, et. al.

[fadden@netcom.com (Andy McFadden)]

In article <B54EAA3F.70AC%burger@contrabandent.com>,
Bill Heineman  <burger@contrabandent.com> wrote:
>Andy, don't put bugs in your code. You'll only have to take them out later.

Right idea, wrong Andy. :-)

Here's what the header from a "bad" archive looks like:

    HeaderID: 'N�F�'  VersionNumber: 0x0003  HeaderCRC: 0x267a
    AttribCount: 60  TotalThreads: 3
    FileSysID: 2 (DOS 3.3)  FileSysInfo: 0x003a (':')
    FileType: 0x00000000  ExtraType: 0x00000118  Access: 0x000000c3
    CreateWhen:     [No Date]     [s0 m0 h0 Y0 D0 M0 x0 w0]
    ModWhen:        [No Date]     [s0 m0 h0 Y0 D0 M0 x0 w0]
    ArchiveWhen: Sat, 02-Jan-2004  02:43:25  [s25 m43 h2 Y4 D1 M0 x0 w7]
    StorageType: 256  OptionSize: 0  FilenameLength: 0
    *ExtraCount: 0  RecFileOffset: 48  RecHeaderLength: 108
[...]
    --Thread #2 (idx=1003)
      ThreadClass:  0x0002 (data_thread)
      ThreadFormat: 0x0003 (dynamic LZW/2)
      ThreadKind:   0x0001 (disk image)
      ThreadCRC: 0xd604  ThreadEOF: 35328  CompThreadEOF: 25689
      *File data offset: 388  actualThreadEOF: 71680
    *TotalCompLength: 25921

According to the NuFX spec, the ThreadEOF is supposed to be the uncompressed
size of the data.  35328 isn't right -- it's supposed to be 140K -- but
most versions of ShrinkIt used some other value (possibly related to the
number of non-empty blocks).

So, NuLib works around it by computing an "actualThreadEOF", which is equal
to the block size (from the StorageType field) times the block count
(ExtraType field).  A "good" disk image is encoded with an ExtraType of 280
and a StorageType of 512, but the "bad" disk image shown above has a block
size of 256.  The above archive claims to hold an image for a 70K disk!

Looks like whatever version of GS/ShrinkIt created the above image filled
in the wrong value for DOS 3.3 disks.  ProDOS disks don't appear to have
the same problem.

The fix is to tweak the calculation of "actualThreadEOF" for this special
case: if the block size is 256 AND the block count is 280 AND it's a DOS
3.3 volume THEN double the size.  This fixes the problem for the two disks
that used to fail, and didn't break it for "ATREE.II.SDK", which is a 140K
ProDOS disk apparently compressed with GSHK.

A v1.0.1 will be out soon...

--
Send mail to fadden@netcom.com (Andy McFadden)
CD-Recordable FAQ - http://www.fadden.com/cdrfaq/ (a/k/a www.spies.com/~fadden)
Fight Internet Spam - http://spam.abuse.net/spam/ & news.admin.net-abuse.email