lhasa unable to unpack correct Amiga LHA archive

[zzarko]

I have a problem with unpacking of some Amiga LHA archives. Just to be sure, I tried to unpack the archive on Amiga and it all went well, no errors (also, no strange Amiga names inside, so that shouldn't be a problem). I have tried to attach the archive to this post, but GitHub won't let me, so it can be taken from:

http://8bitchip.info/commodore/RedLightningLHASAProblem.zip

Inside the zip archive is lha archive that lhasa cannot unpack (I have also tried with the unarchiver, but it also cannot unpack it) and tar.gz archive I made out of unpacked content on Amiga (this is what should be unpacked from archive).

I have made a tool to automate transfer of Amiga games from PC machine to real Amiga and unpacking of LHA archives is integral part of it.

If someone have the time, please take a look...

[polluks]

Another issue, lhasa simply stops after seven of 115 files...
http://aminet.net/package/dev/lib/libgif_a68k

[fragglet]

If it's a separate issue please file a separate bug

…

On Sun, Aug 25, 2019, 5:09 PM Stefan ***@***.***> wrote: Another issue, lhasa simply stops after seven of 115 files... http://aminet.net/package/dev/lib/libgif_a68k — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#31?email_source=notifications&email_token=AAAXUNMDQW4H7Y5MLUQ5Q73QGLYIHA5CNFSM4GUCVI5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5C3YAI#issuecomment-524663809>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAXUNJS2NKRB4LS7QTQ7XLQGLYIHANCNFSM4GUCVI5A> .

[polluks]

DEBUG: member at 0
DEBUG:  header level: 1
DEBUG:  base header size: 46
DEBUG:  cmpr method: "lh5" (LZSS-8K / static Huffman / static Huffman)
DEBUG:  skip size: 437
DEBUG:  original size: 900
DEBUG:  last-modified: 2018-11-23 18:32:46
DEBUG:  filename len: 21
DEBUG:  filename: "RedLightningNTSC.info"
DEBUG:  crc16 (reported): 0x4aa5
DEBUG:  OS id: 65 ('A')
DEBUG:  first ext hdr size: 0
DEBUG:  compressed member data at 48, len=437
DEBUG: member at 485
DEBUG:  header level: 1
DEBUG:  base header size: 25
DEBUG:  cmpr method: "lh0" (uncompressed)
DEBUG:  skip size: 46
DEBUG:  original size: 0
DEBUG:  last-modified: 1989-03-29 11:16:12
DEBUG:  filename len: 0
DEBUG:  filename: ""
DEBUG:  crc16 (reported): 0x0000
DEBUG:  OS id: 65 ('A')
DEBUG:  first ext hdr size: 41
DEBUG:  ext headers section at 512
DEBUG:   ext header at 512, len=41 (1+38+2), id=0x02 (dir name)
DEBUG:    dir name: "RedLightningNTSC<FF>data<FF>devs<FF>clipboards<FF>"
DEBUG:   ext header at 553, len=5 (1+2+2), id=0x00 (common)
DEBUG:    crc16 of header (reported): 0xa370
DEBUG:   size of ext headers section: 46
DEBUG:  uncompressed member data at 558, len=0
DEBUG: member at 558
DEBUG:  header level: 1
DEBUG:  base header size: 29
DEBUG:  cmpr method: "lh5" (LZSS-8K / static Huffman / static Huffman)
DEBUG:  skip size: 890
DEBUG:  original size: 1328
DEBUG:  last-modified: 1989-03-29 11:16:36
DEBUG:  filename len: 4
DEBUG:  filename: "usa1"
DEBUG:  crc16 (reported): 0x15d3
DEBUG:  OS id: 65 ('A')
DEBUG:  first ext hdr size: 38
DEBUG:  ext headers section at 589
DEBUG:   ext header at 589, len=38 (1+35+2), id=0x02 (dir name)
DEBUG:    dir name: "RedLightningNTSC<FF>data<FF>devs<FF>keymaps<FF>"
DEBUG:   ext header at 627, len=5 (1+2+2), id=0x00 (common)
DEBUG:    crc16 of header (reported): 0x5005
DEBUG:   size of ext headers section: 43
DEBUG:  compressed member data at 632, len=847

[...]

[fragglet]

Finally got around to digging into this a bit and finding out what's up with these files. It seems like the problem files have no filename in the normal header (length=0) but instead store their full path in the PATH extended header:

000001e0  ce 5c f0 fc 06 19 e6 2d  6c 68 30 2d 2e 00 00 00  |.\.....-lh0-....|
                         \_ start of header

000001f0  00 00 00 00 06 5a 7d 12  00 01 00 00 00 41 29 00  |.....Z}......A).|
                                              |   \_ os type = amiga ('A')
                                               \_ filename length = 0

00000200  02 52 65 64 4c 69 67 68  74 6e 69 6e 67 4e 54 53  |.RedLightningNTS|
          \_ type 2 extended header = LHA_EXT_HEADER_PATH

00000210  43 ff 64 61 74 61 ff 64  65 76 73 ff 63 6c 69 70  |C.data.devs.clip|
00000220  62 6f 61 72 64 73 ff 05  00 00 70 a3 00 00 1d e0  |boards....p.....|
                                     |         \_ no next header = end of headers
                                      \_ type 0 header

This isn't how the path header is supposed to be used; the compression tool is supposed to generate separate headers for "filename" and "path". So really these are malformed archives. But it should be possible to devise a workaround that catches this case.

[fragglet]

Oh, I missed @jsummers' comment which gives a good theory about what's going on here - that -lhd- directory entries are being mistakenly stored as -lh0-. That gives a good limited condition in which to apply a special-case:

• OS type must be Amiga ('A' = 0x41).
• Compression type must be -lh0-.
• Uncompressed file size must be 0.
• Filename must be NULL and path must be non-NULL.

[polluks]

Maybe we can trackdown the broken version of the tool?
http://se.aminet.net/util/arc/lha_68k.readme