New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Preventing errors of simultaneous access in zipfile #60773
Comments
If the ZipFile was created by passing in a file-like object as the first argument to the constructor, then simultaneous reading or writing of different file results in an non-consistent state. There is a warning about this in the documentation. The proposed patch forces this condition, raising the early exception if you attempt to simultaneously access. I'm not sure whether it's worth apply to older versions. |
I am -0 to this. We can't prevent programmers for shotting in the foot. |
Reading from closed ZipFile or reading from ZipFile opened for write already forbidden. This is a preventing of the same kind. |
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. OTOH, decompressing several files for a given zip file simultaneously does not sound that bad. You know, with all the current file managers, people look at a zip as if it were kind of a directory. |
Indeed. I missed that. Actually these tests work by accident, due to the fact that the contents of the zipfile is placed in the file object buffer.
I agree, but I'm afraid it's impossible to do without performance regression due to seek before every read. And for now ZipFile is not support simultaneous reading when external file object used. Also ZipFile is not thread-safe in any case. You can open several ZipFiles for simultaneous reading. |
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. OTOH, if the seek() call were a problem even if the new position is the same as the old one, they can be optimized out by a simple wrapper around fp. |
Seek can be very cheap. Anybody could actually measure it??? |
I am waiting for an updated patch for bpo-14099 to make benchmarks. |
Compared to the cost of everything else ZipExtFile must do (e.g. 4kb string concatenation in a loop, zlib), its surprising that lseek() would measurable at all. The attached file 'patch' is the minimal change I tested. It represents, in terms of computation and system call overhead, all required to implement the "seek before read" solution to simultaneous access. On OSX, churning over ever member of every ZIP in my downloads directory (about 400mb worth), this change results in around 0.9% overhead compared to the original module. Subsequently I'm strongly against the patch here. It is in effect papering over an implementation deficiency of the current zipfile module, one that could easily and cheaply be addressed. (My comment on this ticket is in the context of the now-marked-duplicate bpo-22842). |
Closed in favor of bpo-14099. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: