Stepan Kasal added the comment:
I agree that reading from a file open for write should be forbidden, no matter
whether ZipFile was called with fp or a name.
Actually, it is not yet forbidden, and two of the tests in the zipfile.py test
suite do actually rely on this misfeature.
The first
Stepan Kasal added the comment:
Re: children counting
You need to know the number of open children and whether the parent ZipFile
object is still open.
As soon as both all children and the parent ZipFile are closed, the underlying
fp (corresponding to the file name given initially) shall
Stepan Kasal added the comment:
but I'm afraid it's impossible to do without performance regression due to
seek before every read.
I agree that this is key question.
I would hope that the performance hit wouldn't be so bad, unless there are
actually two decompressions running concurrently
Stepan Kasal added the comment:
I'm not sure when I'll get to this, sorry.
Hopefully sometime soon.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14099
Stepan Kasal ka...@ucw.cz added the comment:
Attached please find a second iteration of the fix.
This time the signature of ZipExtFile is kept backward compatible, with one new
parameter added.
--
Added file:
http://bugs.python.org/file24624/Proposed-fix-of-issue14099-second.patch
New submission from Stepan Kasal ka...@ucw.cz:
When a file inside a zip is open, the underlying zip file is open again.
(Unless the file name is unknown, because the ZipFile object was created with
fp only.)
This design is incorrect, insecure, and ineffective:
- the reopen uses the same string
Stepan Kasal ka...@ucw.cz added the comment:
Attached please find a patch that fixes this issue by reusing the original fp
from ZipFile object.
Two of the test cases attempted to read a file from a zip as soon as write()
was called. I believe that this is not correct usage: zip file
