commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zbynek Vyskovsky (JIRA)" <>
Subject [jira] [Commented] (COMPRESS-390) Expose zip stream offset and size via API
Date Wed, 26 Apr 2017 18:48:04 GMT


Zbynek Vyskovsky commented on COMPRESS-390:

[~bodewig] : I absolutely agree that for many archive types it wouldn't make sense and that's
the reason for default (dummy) implementation returning -1. On the other hand, I believe there
are more archive types where this information would be useful - I was thinking about 7z at
least. To keep the abstraction - in case the user doesn't want to take care what's the underlying
archive implementation, I decided to put it into common interface. In case the user wants
to use this information, he expects the archive to be in format providing that information
but still doesn't have to be completely aware of exact implementation and can change it at
any time.

About your comment for 7z - I didn't really check the details. But generally, this offsets
are useful mainly for direct mapping into memory, i.e. in cases when there is just single
archive and preferably the data is just stored. I didn't go so much into details for 7z so
my expectations about it might be wrong.

About header offset: It exposes local file header, I don't see any difference, they should
be usually the same, don't they? Well, not in terms of size, crc etc when it's written as
a stream, right? It can be updated anyway to expose the central directory header offset. Anyway,
the data offset is far more important information, the header would be rather useful for kind
of investigation.

> 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