[
https://issues.apache.org/jira/browse/COMPRESS-565?focusedWorklogId=559918&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-559918
]
ASF GitHub Bot logged work on COMPRESS-565:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 02/Mar/21 12:16
Start Date: 02/Mar/21 12:16
Worklog Time Spent: 10m
Work Description: bodewig edited a comment on pull request #169:
URL: https://github.com/apache/commons-compress/pull/169#issuecomment-788865243
> This means we should encode the relative offset and disk number at the
same time - even through only eithor of them is too big. Am I right about it?
No, this is not what I meant.
In the layout of the ZIP64 extended information extra field you have the two
sizes - which must always be present - then the LFH offset, then the disk
number. If you don't need to encode the LFH offset but have to encode the disk
number the disk number would appear directly after the sizes. I'm afraid there
might be parsers that try to read the LFH offset anyway if the size of the
extra field is bigger than the two size fields. So I'd encode both, even if
only the disk number needs to be encoded - and would be willing to encode the
LFH offset (when needed) without encoding the disk number.
I may be overcautious (the parser should consult the corresponding field
inside of the central directory actually contains FFs and it should see the
size is only 20 bytes not 24 or even 28) but prefer to stay on the safe side.
Also, this is an edge case of an edge case - I don't expect us to ever create
archives with more than 64k parts.
`AlwaysWithCompatibility` sounds a lot better, thanks :-)
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 559918)
Time Spent: 1h 50m (was: 1h 40m)
> Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
> -----------------------------------------------------------------------
>
> Key: COMPRESS-565
> URL: https://issues.apache.org/jira/browse/COMPRESS-565
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
> Affects Versions: 1.20
> Reporter: Evgenii Bovykin
> Assignee: Peter Lee
> Priority: Major
> Attachments: commons-compress-1.21-SNAPSHOT.jar,
> image-2021-02-20-15-51-21-747.png
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> We've recently updated commons-compress library from version 1.9 to 1.20 and
> now experiencing the problem that didn't occur before.
>
> When using ZipArchiveOutputStream to archive 5Gb file and setting the
> following fields
> {{output.setUseZip64(Zip64Mode.Always)}}
>
> {{output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)}}
> resulting archive contains corrupted headers.
> *Expand-Archive Powershell utility cannot extract the archive at all with the
> error about corrupted header. 7zip also complains about it, but can extract
> the archive.*
>
> The problem didn't appear when using library version 1.9.
>
> I've created a sample project that reproduces the error -
> [https://github.com/missingdays/commons-compress-example]
> Issue doesn't reproduce if you do any of the following:
>
> # Downgrade library to version 1.9
> # Remove
> output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)
> # Remove output.setUseZip64(Zip64Mode.Always) and zip smaller file (e.g. 1Gb)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
