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

SourceForge.net noreply at sourceforge.net
Thu Nov 13 14:51:00 EST 2003


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-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



More information about the Python-bugs-list mailing list