You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
The FileHeader.Extra field is used by the Writer 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.
How would adding ExtraCentral field work with readers? Would ExtraCentral be always nil when reading from the archive?
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 Reader.init.
However, if we used ExtraCentral also for reading, then we'd probably need to change Extra to contain data from local file header instead of central directory record. That could break some existing code if an archive contains different data in local file header and central directory record.
If we add ExtraLocal field instead of ExtraCentral, we won't have this problem and the semantics when reading would be more clear (Extra is from central directory, ExtraLocal is nil because we didn't read the local file header).