[issue16569] Preventing errors of simultaneous access in zipfile

Serhiy Storchaka added the comment: Closed in favor of issue14099. -- resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker ___ _

[issue16569] Preventing errors of simultaneous access in zipfile

David Wilson added the comment: 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 an

[issue16569] Preventing errors of simultaneous access in zipfile

Changes by Serhiy Storchaka : -- Removed message: http://bugs.python.org/msg176851 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue16569] Preventing errors of simultaneous access in zipfile

Changes by Serhiy Storchaka : -- Removed message: http://bugs.python.org/msg176850 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue16569] Preventing errors of simultaneous access in zipfile

Changes by Serhiy Storchaka : -- assignee: -> serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue16569] Preventing errors of simultaneous access in zipfile

Serhiy Storchaka added the comment: > Seek can be very cheap. Anybody could actually measure it??? I am waiting for an updated patch for issue14099 to make benchmarks. -- ___ Python tracker ___

[issue16569] Preventing errors of simultaneous access in zipfile

Jesús Cea Avión added the comment: Seek can be very cheap. Anybody could actually measure it??? -- ___ Python tracker ___ ___ Python-b

[issue16569] Preventing errors of simultaneous access in zipfile

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

[issue16569] Preventing errors of simultaneous access in zipfile

Serhiy Storchaka added the comment: > Actually, it is not yet forbidden, and two of the tests in the zipfile.py > test suite do actually rely on this misfeature. Indeed. I missed that. Actually these tests work by accident, due to the fact that the contents of the zipfile is placed in the fil

[issue16569] Preventing errors of simultaneous access in zipfile

Serhiy Storchaka added the comment: Test: file24624/Proposed-fix-of-issue14099-second.patch -- ___ Python tracker ___ ___ Python-bugs

[issue16569] Preventing errors of simultaneous access in zipfile

Serhiy Storchaka added the comment: Test: http://bugs.python.org/file24624/Proposed-fix-of-issue14099-second.patch file24624 -- ___ Python tracker ___ _

[issue16569] Preventing errors of simultaneous access in zipfile

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 chunk

[issue16569] Preventing errors of simultaneous access in zipfile

Serhiy Storchaka added the comment: Reading from closed ZipFile or reading from ZipFile opened for write already forbidden. This is a preventing of the same kind. -- ___ Python tracker

[issue16569] Preventing errors of simultaneous access in zipfile

Jesús Cea Avión added the comment: I am -0 to this. We can't prevent programmers for shotting in the foot. -- nosy: +jcea ___ Python tracker ___ _

[issue16569] Preventing errors of simultaneous access in zipfile

New submission from Serhiy Storchaka: 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 propose