[ python-Bugs-835145 ] [2.3.2] zipfile test failure on AIX 5.1

[SourceForge.net]

Bugs item #835145, was opened at 2003-11-03 08:06
Message generated for change (Comment added) made by tww-china
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835145&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: The Written Word (Albert Chin) (tww-china)
Assigned to: Nobody/Anonymous (nobody)
Summary: [2.3.2] zipfile test failure on AIX 5.1

Initial Comment:
$ cd /opt/build/Python-2.3.2
$ ./python -E -tt Lib/test/test_zipfile.py
Traceback (most recent call last):
  File "Lib/test/test_zipfile.py", line 35, in ?
    zipTest(file, zipfile.ZIP_STORED, writtenData)
  File "Lib/test/test_zipfile.py", line 13, in zipTest
    zip.close()
  File "/opt/build/Python-2.3.2/Lib/zipfile.py", line
503, in close
    zinfo.header_offset)
OverflowError: long int too large to convert
Exception exceptions.OverflowError: 'long int too large
to convert' in <bound method ZipFile.__del__ of
<zipfile.ZipFile instance at 0x20308da0>> ignored

The test passes just fine on AIX 4.3.2.

This is against a Python built with the IBM v6 C
compiler and GCC 3.3.2.

I added some debugging print statements to
Lib/zipfile.py and it seems that zinfo.external_attr is
out of whack. On AIX 4.3.2, the value for this variable
is "2176057344" while on AIX 5.1 it is "10765991936".

I tracked this back to the following line in the write
method of Lib/zipfile.py:
        zinfo.external_attr = st[0] << 16L      # Unix
attributes
On AIX 4.3.2, st[0] is 33204 while on AIX 5.1 it is
164276. In python 2.2.x, it was '<< 16' which resulted
in a signed value on AIX 5.1. I really don't think you
can use the 16L as mode_t on AIX is unsigned int. Ditto
for other platforms. Why not just store st[0] unchanged?

----------------------------------------------------------------------

>Comment By: The Written Word (Albert Chin) (tww-china)
Date: 2003-11-30 15:47

Message:
Logged In: YES 
user_id=119770

Ok, your (st[0] & 0xffff) change should be ok. AIX has
several file systems available, among them JFS and JFS2.
zipfile.py works fine on JFS and NFS file systems but not
JFS2. The 0xffff change throws away the extra bits but it
shouldn't matter.

I checked the zip source and they don't & with 0xffff but
they have the same problem. However, because the shift by 16
is constrained by the maxint(unsigned short), we don't run
into the same problem with the zip source as with Python
which promotes the int to a long.

----------------------------------------------------------------------

Comment By: The Written Word (Albert Chin) (tww-china)
Date: 2003-11-13 10:51

Message:
Logged In: YES 
user_id=119770

The suggestion works. I want to look through the zip-2.3
source though. I'll do so this weekend.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-11-13 10:11

Message:
Logged In: YES 
user_id=6380

So Albert, any luck with my suggestion?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-11-10 07:43

Message:
Logged In: YES 
user_id=6380

It looks like what is happening is that the mode returned by
stat() has a bit beyond the 16th set. I'm guessing that
those extra bits should be ignored -- there is no room for
them in the header it seems.

Could you try replacing st[0] with (st[0] & 0xffff) in that
expression and then try again?

(Hm, I wonder why the Unix mode is left-shifted 16 bits.
Maybe the real definition of "external attributes" is a bit
different? What is supposed to be stored in those lower 16
bits that always appear to be zero? I don't have time to
research this.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835145&group_id=5470