Bug report

Bug description:

Zip implementations interpret the zip appnote with regards to offset fields in the central directory differently centDirOffset (offset of start of central directory with respect to the starting disk number) and relative offset of local header. Some implementations will store the number of bytes from the first local header (eg. 7zip - I tested by adding self extracting content with 7zz) while others will store the number of bytes from the start of the file (eg. infozip, python's zipfile which I didn't expect!). The two approaches only produce different results when data is prepended to an archive.

When prepended data is present, ZipFile.data_offset will contain different values for the different implementations.

Taking the example provided by @danny0838 in this comment: #134627 (comment)

with open('archive.zip', 'wb') as fh:
    fh.write(b'dummy')
    with zipfile.ZipFile(fh, 'a') as zh:
        zh.writestr('file', 'file content')

with zipfile.ZipFile('archive.zip') as zh:
    print(zh.data_offset)  # 0
    print(zh.infolist()[0].header_offset)  # 5
    print(zh.start_dir)  # 51

zh.data_offset should be 5

Related: #84481

CPython versions tested on:

3.14

Operating systems tested on:

macOS

Linked PRs

• gh-136170: Use earliest zinfo.header_offset as ZipFile.data_offset #136171
• gh-136170: Revert adding ZipFile.data_offset #136950
• [3.14] gh-136170: Revert adding ZipFile.data_offset (GH-136950) #136955