random access uncompressed unencrypted ZipExtFile

Feature or enhancement

Proposal:

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

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

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.

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

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).

GH-128131: Completely support random read access of uncompressed unen…

pythonGH-128131: Completely support random read access of uncompresse…

[3.13] GH-128131: Completely support random read access of uncompress…

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

[3.12] GH-128131: Completely support random read access of uncompress…

Closing since completed and backported. Thank you everyone.

pythonGH-128131: Completely support random read access of uncompresse…

Navigation Menu

Repository navigation

random access uncompressed unencrypted ZipExtFile #128131

Feature or enhancement

Proposal:

Has this already been discussed elsewhere?

Links to previous discussion of this feature:

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

	# 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

random access uncompressed unencrypted ZipExtFile #128131

Description

Feature or enhancement

Proposal:

Has this already been discussed elsewhere?

Links to previous discussion of this feature:

Linked PRs

Activity

danifus commented on Dec 22, 2024

jaraco commented on Dec 26, 2024

vvb2060 commented on Dec 31, 2024

jaraco commented on Jan 20, 2025

picnixz commented on Jan 20, 2025

picnixz commented on Jan 20, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions