Message73317
| Author |
markhirota |
| Recipients |
alanmcintyre, arkanes, georg.brandl, markhirota |
| Date |
2008年09月16日.21:53:30 |
| SpamBayes Score |
4.784263e-06 |
| Marked as misclassified |
No |
| Message-id |
<1221602063.76.0.529945396943.issue1757072@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
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. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2008年09月16日 21:54:23 | markhirota | set | recipients:
+ markhirota, georg.brandl, alanmcintyre, arkanes |
| 2008年09月16日 21:54:23 | markhirota | set | messageid: <1221602063.76.0.529945396943.issue1757072@psf.upfronthosting.co.za> |
| 2008年09月16日 21:53:30 | markhirota | link | issue1757072 messages |
| 2008年09月16日 21:53:30 | markhirota | create |
|