Issue835145
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2003-11-03 17:06 by tww-china, last changed 2022-04-11 14:56 by admin. This issue is now closed.
Messages (6) | |||
---|---|---|---|
msg18871 - (view) | Author: The Written Word (Albert Chin) (tww-china) | Date: 2003-11-03 17:06 | |
$ 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.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? |
|||
msg18872 - (view) | Author: Guido van Rossum (gvanrossum) * | Date: 2003-11-10 16:43 | |
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.) |
|||
msg18873 - (view) | Author: Guido van Rossum (gvanrossum) * | Date: 2003-11-13 19:11 | |
Logged In: YES user_id=6380 So Albert, any luck with my suggestion? |
|||
msg18874 - (view) | Author: The Written Word (Albert Chin) (tww-china) | Date: 2003-11-13 19:51 | |
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. |
|||
msg18875 - (view) | Author: The Written Word (Albert Chin) (tww-china) | Date: 2003-12-01 00:47 | |
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. |
|||
msg18876 - (view) | Author: A.M. Kuchling (akuchling) * | Date: 2004-07-10 15:57 | |
Logged In: YES user_id=11375 I've committed the suggested change to both CVS HEAD and the 2.3 branch. Thanks for reporting the problem! |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:56:00 | admin | set | github: 39493 |
2003-11-03 17:06:55 | tww-china | create |