[issue10694] zipfile.py end of central directory detection not robust
R. David Murray
report at bugs.python.org
Mon Dec 20 02:22:11 CET 2010
R. David Murray <rdmurray at bitdance.com> added the comment:
Actually our normal procedure currently (this will change a bit after the migration to mercurial) is a patch against the py3k branch, and the committer will do the backport to the other active branches. If the 2.7 code is very different, a separate 2.7 patch is sometimes helpful. In this case it looks like a patch that applies to py3k is enough.
Alan hasn't spoken up yet, and he's listed as maintainer. If he doesn't speak up someone else will hopefully make a decision before the end of the beta period for 3.2. I'm bumping up the priority of this issue because I think not being able to handle commonly produced archives that other zip tools can handle is a relatively serious defect.
My own opinion is that truncation if the extra data doesn't look like a comment makes the most sense. But absent an opinion from Alan I think I'd be guided by whatever other zip tools do in this case. Kevin, am I correct in guessing that that is truncation?
Ned is definitely correct that absence of a test case is something that can delay getting a patch applied. If a patch includes a unit test, a committer can often do a quick review-and-apply, while absent a unit test the committer would first need to write one, and therefore will often move on to some other, easier to process issue :) In this case it seems to me that the unit test will only differ in one detail depending on the fix chosen, so it may be worth writing it even before a final decision is made, if you are willing.
----------
nosy: +r.david.murray
priority: normal -> high
stage: needs patch -> unit test needed
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10694>
_______________________________________
More information about the Python-bugs-list
mailing list