ZipExtFile:_update_crc fails for CRC >= 0x80000000

[arindam]

BPO	10903
Nosy	@pitrou
Files	a.zip: test zip file

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2011-01-17.19:42:38.310>
created_at = <Date 2011-01-14.09:43:32.403>
labels = ['invalid', 'type-bug', 'library']
title = 'ZipExtFile:_update_crc fails for CRC >= 0x80000000'
updated_at = <Date 2011-01-17.19:42:38.309>
user = 'https://bugs.python.org/arindam'

bugs.python.org fields:

activity = <Date 2011-01-17.19:42:38.309>
actor = 'arindam'
assignee = 'none'
closed = True
closed_date = <Date 2011-01-17.19:42:38.310>
closer = 'arindam'
components = ['Library (Lib)']
creation = <Date 2011-01-14.09:43:32.403>
creator = 'arindam'
dependencies = []
files = ['20425']
hgrepos = []
issue_num = 10903
keywords = []
message_count = 8.0
messages = ['126250', '126278', '126353', '126408', '126420', '126427', '126428', '126432']
nosy_count = 4.0
nosy_names = ['pitrou', 'nadeem.vawda', 'srid', 'arindam']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue10903'
versions = ['Python 2.7']

[arindam]

File: zipfile.py
Function: _update_crc
statement: if eof and self._running_crc != self._expected_crc:

Due to comparison of long with int, "if eof and self._running_crc != self._expected_crc:" fails when _expected_crc is negative (0x80000000 or more). Type of _running_crc is long while _expected_crc is int.

How to reproduce: Unzip a zip file containing a file having CRC >= 0x80000000.

The issue is seen with 3.1 also.

[pitrou]

Can you provide such a file? What system are you testing on?

[nadeemvawda]

I have been unable to reproduce this on either 3.2rc1 or 2.6. I used a Zip archive containing a single file with the data b"a\n" (CRC 0xDDEAA107).

[arindam]

Attached test file a.zip. Happening with 2.7.1.3. The changes came with /python/branches/release27-maint/Lib/zipfile.py revision 83961

[pitrou]

Attached test file a.zip. Happening with 2.7.1.3. The changes came
with /python/branches/release27-maint/Lib/zipfile.py revision 83961

I tested with 2.7.x and 3.2 (both from latest SVN) and couldn't reproduce (I used testzip() and extractall()), both in 32-bit and 64-bit builds.

Can you clarify which OS you are using? Also, what is 2.7.1.3? We don't have a such version (see http://python.org/download/releases/ for official releases). If you are using a Python provided by a third-party distributor (such as ActiveState or a Linux distribution), you might want to report the bug to them, since AFAICT the bug doesn't exist on the official builds.

[arindam]

Able to get the issue with
Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32

This is the latest version for 2.7.x

Please try with the uploaded a.zip

[pitrou]

Able to get the issue with
Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32

Ok, I tried with this exact version and I still can't reproduce.
Can you explain which steps exactly are necessary to exhibit this issue?

[arindam]

Legacy code in my module was setting zipfile.structCentralDir to "<4s4B4H3l5H2L" (was added to fix some issues with older version of python) was the root cause of this issue. Sorry, should have checked before filing. Thanks for your time. Sorry once again.