#1123798 macutils: macunpack reports spurious 'Header CRC mismatch' on CompactPro archive

Package:
macutils
Source:
macutils
Description:
Set of tools to deal with specially encoded Macintosh files
Submitter:
Joseph Oswald
Date:
2026-01-14 01:55:02 UTC
Severity:
normal
#1123798#5
Date:
2025-12-21 21:29:15 UTC
From:
To:
Dear Maintainer,

Using macunpack from macutils to unpack a CompactPro archive results in an
error message

     Header CRC mismatch: got 0x79c895e4, need 0xebae4ed4

However, the CPT file unpacks successfully using CompactPro 1.52 on an
emulated Macintosh.

It appears the problem is that macunpack uses (unsigned long) 64-bit integers
for the computation of the "Zip CRC", but the CRC computation of CompactPro
only uses 32 bits.

Patching several unsigned long -> uint32_t values allows macunpack to decode
the archive.

(This was reported 'downstream' as
https://bugs.launchpad.net/ubuntu/+source/macutils/+bug/2136046)

I would be willing to develop a patch, however I am not particularly familiar
with the development and build process you prefer, and extensively updating
the 16/32-bit dependencies in the code potentially touches many files.
#1123798#10
Date:
2025-12-27 17:08:34 UTC
From:
To:
I hope this is a properly formatted patch file with a minimal fix for the
bug.
I also submitted this patch downstream on Ubuntu Launchpad
#1123798#15
Date:
2025-12-27 20:43:26 UTC
From:
To:
Thanks, Joseph.  I'll do some testing and try to get this uploaded within a
few days.

Eric
#1123798#20
Date:
2026-01-04 18:48:32 UTC
From:
To:
Finally getting around to looking at this.  The patch includes this bit:

+-    (void)fprintf(fd, "unsigned long %s_crcinit = %d;\n", name, init);
++    (void)fprintf(fd, "#include <stdint.h>\n\n");
++    if (bits == 16) {
++      (void)fprintf(fd, "uint16_t %s_crcinit = %d;\n", name, init);
++    } else {
++      (void)fprintf(fd, "uint32_t %s_crcinit = %d;\n", name, init);
++    }

Which changes the number of bits in the initial value, but this initial
value is used to initialize the global element defined in crc.c as:

unsigned long crcinit;

e.g., in macunpack/cpt.c:

    crcinit = zip_crcinit;

and macunpack/crc.h still declares these as:

extern unsigned long arc_crcinit;
extern unsigned long binhex_crcinit;
extern unsigned long zip_crcinit;

which isn't modified by your patch, so the headers get out of sync with the
actual code generated by makecrc.  It probably works in practice, but this
should be cleaned up before being uploaded.

Eric
#1123798#25
Date:
2026-01-13 04:22:16 UTC
From:
To:
Thanks for looking it over.

Fair enough, my initial patch was deliberately intended to be minimal, but
if you would prefer my updating the uses of the libraries I can do that,
although the changes will touch several more files.

I think I have it working on my local git repo, it will take me a bit for
me to convert it into the patch format.
#1123798#30
Date:
2026-01-14 01:53:11 UTC
From:
To:
Eric--

How about the attached? It combines the previous minimal fix, and I think
updates all the call sites for CRC routines.