[
https://issues.apache.org/jira/browse/COMPRESS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anvesh Mora updated COMPRESS-500:
---------------------------------
Attachment: invalidzip.zip.partai
> Discrepancy in file size extracted using ZipArchieveInputStream and Gzip
> decompress component
> ----------------------------------------------------------------------------------------------
>
> Key: COMPRESS-500
> URL: https://issues.apache.org/jira/browse/COMPRESS-500
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
> Affects Versions: 1.8, 1.18
> Reporter: Anvesh Mora
> Priority: Major
> Attachments: invalidzip.zip.partaa, invalidzip.zip.partah,
> invalidzip.zip.partai
>
>
> Recent time I raised a bug facing a issue of "invalid Entry Size"
> COMPRESS-494 ( Not resolved yet).
>
> And we are seeing a new issue, before explaining we have a file structure as
> below and it is received as a stream of data over HTTPS.
>
> *File Structure*:
> In Zip file
> We have zero or more gz files which need to decompressed
> And meta data at the end of the zip entries (end of stream), used for
> downloading next file zip file. As plain text.
>
> And Now in production we are seeing new issue where we the entire gz file is
> not decompressing. We found out that the utility on Cent OS7 is able to
> extract and decompress the entire where as our library is failing. Below are
> the differences in Sizes:
> Using API: *765460480* bytes
> And using Cent OS7 Linux utilities: *2032925215* bytes.
>
> We are getting EOF File exception at GzipCompressorInputStream.java:278, I'm
> not sure of why.
>
> Need you help on this as we are blocked in the production. This could be a
> potential fix for our library to make it more robust.
>
> Let me know HOW CAN WE INCREASE THE PRIORITY IF NEEDED!
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
