Stepan Kasal added the comment:
I'm not sure when I'll get to this, sorry.
Hopefully sometime soon.
--
___
Python tracker
<http://bugs.python.o
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 d
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 be
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:
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
Stepan Kasal 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 is not even
fully
New submission from Stepan Kasal :
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 as file
