archive/zip: FileHeader.Extra API is problematic #22520
Comments
@dsnet This is currently set for the 1.11 milestone. Please update as appropriate. Thanks. |
I suggest we add ExtraCentral []byte, where a writer treats nil to mean "same as Extra". |
My use case is to read the Extra field from local file headers, as httrack only writes data to the local file headers and the extra data in central directory record is empty. See also #40354 (comment) How would adding Currently when reading, we read the central directory only. Reading the local file header in addition to it is expensive as we'd need to seek to read the data for each file and most of the time users don't care about the differences in local file header/central directory. So I think we don't want to read the local file headers in However, if we used If we add |
The
FileHeader.Extra
field is used by theWriter
to write the "extra" field for the local file header and the central-directory file header. This is problematic because the Go implementation assumes that the extra bytes used in the two headers are the same. While is this is often the case, it is not always true.See http://mdfs.net/Docs/Comp/Archiving/Zip/ExtraField and you will notice that it frequently describes a "Local-header version" and a "Central-header version", where the formats sometimes differ.
The
Reader
does not have this problem because it entirely ignores the local headers.I haven't thought much about what the right action is moving forward, whether to deprecate this field or add new API. I just want to file this issue, so I remember to address it later.
The text was updated successfully, but these errors were encountered: