zipfile and Tru64 UNIX

[Albert Chin-A-Young]

Albert Chin-A-Young <china at thewrittenword.com> wrote:
> Anyone aware of problems with zipfile against Python 2.0.1, 2.1.2, or
> 2.2.1 and 64-bit systems like Tru64 UNIX? I'm testing against 4.0D and
> 5.1 and a zipfile that tests out using testzip() on IRIX, HP-UX, and
> Solaris gives a CRC error on Tru64 UNIX. I've tried creating the zipfile
> with the UNIX zip program or zip.write() and get the same error. The
> only bug I could find on sf.net was:
>  http://sourceforge.net/tracker/index.php?func=detail&aid=453208&group_id=5470&atid=105470
> 
>> import zipfile
>> zip=zipfile.ZipFile('/tmp/a.zip','r')
>> zip.printdir()
> File Name                                             Modified             Size
> vmunix                                         2002-05-31 14:29:06      9225952
>> foo=zip.read('vmunix')
> Traceback (most recent call last):
>  File "<stdin>", line 1, in ?
>  File "/opt/TWWfsw/python221/lib/python2.2/zipfile.py", line 354, in
> read
>    raise BadZipfile, "Bad CRC-32 for file %s" % name
> zipfile.BadZipfile: Bad CRC-32 for file vmunix
>> bar=zip.getinfo('vmunix')
>> bar.CRC
> -2068761705
> 
> The output of binascii.crc32 on the contents of 'vmunix' is:
>  2226205591
> or from the unzip program:
>  $ unzip -v /tmp/a.zip
>  Archive:  /tmp/a.zip
>   Length   Method    Size  Ratio   Date   Time   CRC-32    Name
>  --------  ------  ------- -----   ----   ----   ------    ----
>   9225952  Stored  9225952   0%  05-31-02 14:29  84b13397  vmunix
>  --------          -------  ---                            -------
>   9225952          9225952   0%                            1 file
> 
> Adding some debugging statements to zipfile.py reveals that the CRC
> returned by binascii.crc32() is 2226205591 which is 0x84b13397. So, this
> matches the output above from unzip. So, bar.CRC is wrong.
> 
> BTW, the /tmp/a.zip file used in this example was written with the
> zipfile module (it is a valid zip file as I unpack with unzip and ran
> cmp against /vmunix, the original source).

Ok, I did some digging. The attached patch solves the problem. I think
this is a problem for any machine where sizeof(long) == 8. Is there an
easier way to force crc to be a 32-bit int. From the typesnumeric.html
document:
  Plain integers (also just called integers) are implemented using
  long in C, which gives them at least 32 bits of precision.

-- 
albert chin (china at thewrittenword.com)

-- snip snip
--- Lib/zipfile.py.orig	Mon Jul  1 23:10:00 2002
+++ Lib/zipfile.py	Mon Jul  1 23:10:26 2002
@@ -346,7 +346,7 @@
             raise BadZipfile, \
                   "Unsupported compression method %d for file %s" % \
             (zinfo.compress_type, name)
-        crc = binascii.crc32(bytes)
+        crc = struct.unpack('<l', struct.pack('<l', binascii.crc32(bytes)))[0]
         if crc != zinfo.CRC:
             raise BadZipfile, "Bad CRC-32 for file %s" % name
         return bytes