commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Bodewig (JIRA)" <>
Subject [jira] [Commented] (COMPRESS-390) Expose zip stream offset and size via API
Date Thu, 27 Apr 2017 04:32:04 GMT


Stefan Bodewig commented on COMPRESS-390:

My memory of 7z isn't too fresh, but I don't think it will work that easily, in particular
not for archives using block compression. Headers are organized differently as well with information
about multiple entries combined into bitsets, so there is no defined single header per entry.

bq. It exposes local file header, I don't see any difference, they should be usually the same,
don't they?

Not at all, unfortunately. The central directory always has sizes, the LFH may not, for example
when a data descriptor has been used when creating a  non-searchable output. Extra fields
may have different contents in both cases with the one in the LFH only containing a subset
of the information present inside the central directory in many cases. 

How about we add the extra information needed for your use-case to Zip now, maybe even in
an extension of {{ZipArchiveEntry}}? We can think about generalizing the solution once we
really want to provide it to other formats as well.

> Expose zip stream offset and size via API
> -----------------------------------------
>                 Key: COMPRESS-390
>                 URL:
>             Project: Commons Compress
>          Issue Type: New Feature
>          Components: Archivers
>    Affects Versions: 1.13
>            Reporter: Zbynek Vyskovsky
>              Labels: features, github-import, patch
>             Fix For: 1.14
> In certain cases it may be useful to get information about where in the archive the stream
starts and ends. Typically when zip is used as resource container and the resources are then
mapped directly into memory, but not only.
> The size and compressed size are already available but not the stream offset.
> This can be applied to other archive types as well, therefore it would make sense to
put this into basic interface - ArchiveEntry. But not necessarily all of them have to support

This message was sent by Atlassian JIRA

View raw message