commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Bodewig (JIRA)" <>
Subject [jira] [Commented] (COMPRESS-391) Zip entries alignment
Date Wed, 10 May 2017 04:22:04 GMT


Stefan Bodewig commented on COMPRESS-391:

[~kvr] don't worry. I'm eager to get 1.14 out, that's why I started to implenent something

bq. I think it might make sense to take the length from extra once re-populated

True, but for a different reason. {{addExtraField}} replaces an existing extra field using
the same id, so if there has already been an extra field by that id the length of extra would
be different. It will be cleaner to try removing an existing padding field (or adjusting,
I'm bad at names :-), recalculate the size, add one, and maybe recalculate the size again.
I'll modify the patch accordingly. This should address your concern about previously existing
alignment and having only one instance of the extra field.

The field is really only useful when writing the archive, so I don't think we need to perform
any special step when alignment changes. This should be addressed when the entry with the
changed alignment is written (again) - something that should happen when I modify the existing

WRT the id I understood we would mimic "prior art" used by zipalign. We should use the same
id it uses. As for Zip RFC, I'm not sure about the process, or if there is a process at all.

> Zip entries alignment
> ---------------------
>                 Key: COMPRESS-391
>                 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
> Similarly to COMPRESS-390, there are requirements of the zip content to be mapped directly
into memory and therefore may require special alignment on the embedded files. E.g. libraries
may be aligned to page (4096-bytes) boundary, images on 4-bytes boundary etc. By alignment
it's meant the offset from the beginning of file where the actual data stream starts, not
the header.
> One of the cases was (still is?) Android APK for which zipalign utility was created.
> It would be useful if commons-compress ZipArchiveOutputStream supports something similar
directly in its API.

This message was sent by Atlassian JIRA

View raw message