commons-issues mailing list archives

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


Zbynek Vyskovsky commented on COMPRESS-391:

[~bodewig] : Oh, I should be faster in implementing the patches if I don't want to wait for
another release :-) Thanks for this!

I think first the field can be removed completely and then only added if the alignment doesn't
match. Although with approach you mentioned the copying of alignment would still work as long
as the old files streams and structure remains exactly the same... which is kind of fragile

I believe it would still make sense to write the requested alignment value (not padding value)
as part of the payload, it's just two bytes anyway and it may be used later when someone implements
both reading and writing part. Additionally, in such case this extra field should be written
always, not only when alignment doesn't match, as it contains important information for re-zipping.

About zipalign: As far as I remember, they simply add enough zeroes at the end of extra fields,
they even don't create the id header, its size etc. So the result is not really correct zip
stream but I assume the readers simply ignore it. So no "prior art" here...

About Zip RFC: According to , there is an
e-mail for proposing enhancements. I can write and update here. 0xalle (id), 0x0002 (size),
short (alignment) sounds good? :-)

> 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