[issue1757072] Zipfile robustness

[Mark Hirota]

Mark Hirota <markhirota at users.sourceforge.net> added the comment:

I'd like to piggyback on this issue if okay :D

I have some zipfiles I'm working with that contain junk in the extra 
fields. The ZipFile object croaks at the call to the 
ZipInfo._decodeExtra() call when it could really just ignore the error.

Example of traceback:

>>> zf = zipfile.ZipFile('bad.zip', 'r')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "zipfile.py", line 346, in __init__
    self._GetContents()
  File "zipfile.py", line 366, in _GetContents
    self._RealGetContents()
  File "zipfile.py", line 424, in _RealGetContents
    x._decodeExtra()
  File "zipfile.py", line 267, in _decodeExtra
    tp, ln = unpack('<hh', extra[:4])
  File "/usr/lib/python2.5/struct.py", line 87, in unpack
    return o.unpack(s)
struct.error: unpack requires a string argument of length 4

While I'm working to track down the source of the "extra junk" -- this 
type of error falls into the same category: Python zipfile hits an 
issue that most zip tools are fine with.

----------
nosy: +markhirota

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1757072>
_______________________________________