random access uncompressed unencrypted ZipExtFile

[vvb2060]

Feature or enhancement

Proposal:

cpython/Lib/zipfile/__init__.py

Lines 1164 to 1177 in 78ffba4

	# Fast seek uncompressed unencrypted file
	elif self._compress_type == ZIP_STORED and self._decrypter is None and read_offset > 0:
	# disable CRC checking after first seeking - it would be invalid
	self._expected_crc = None
	# seek actual file taking already buffered data into account
	read_offset -= len(self._readbuffer) - self._offset
	self._fileobj.seek(read_offset, os.SEEK_CUR)
	self._left -= read_offset
	read_offset = 0
	# flush read buffer
	self._readbuffer = b''
	self._offset = 0
	elif read_offset < 0:
	# Position is before the current position. Reset the ZipExtFile

if read_offset < 0, ZipExtFile is reset and read from the beginning. I think read_offset > 0 is unnecessary.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

Linked PRs

• GH-128131: Random access uncompressed unencrypted ZipExtFile #128132
• GH-128131: Completely support random read access of uncompressed unencrypted files in ZipFile #128143
• [3.13] GH-128131: Completely support random read access of uncompressed unencrypted files in ZipFile (GH-128143) #129091
• [3.12] GH-128131: Completely support random read access of uncompressed unencrypted files in ZipFile (GH-128143) #129092

[danifus]

There is a bug in zipfile._SharedFile.seek() that affects concurrent reads of uncompressed, unencrypted files which should be merged along with this PR: #127856

[jaraco]

Can you revise the original post to clarify what’s going on here? I read it, but I don’t understand: what is wrong with the current behavior? Under what conditions do the problems occur and thus who is affected? What do you expect instead? Just articulate as much as you can so it’s clear from the problem description what the proposed improvement is.

[vvb2060]

#27737 does not really support random access, currently zipfile can only read uncompressed unencrypted ZipExtFile sequentially (only forward seek).

[jaraco]

Thanks vvb2060. Let me re-articulate what I think you're saying.

In #27737, the zipfile module introduced the possibility of seeking within a zip file, but only for compressed or encrypted payloads. Today, if someone attempts to seek with an offset that's 0 or negative, the wrong logic is reached, and an error occurs. Instead, it should be straightforward to enable seeking in any direction (any value of read_offset) consistently (for unencrypted, uncompressed files).

[picnixz]

See #128143 (comment) for the rationale of backports and the type-bug label.

[picnixz]

Closing since completed and backported. Thank you everyone.