[ https://issues.apache.org/jira/browse/COMPRESS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17025042#comment-17025042 ]
Anvesh Mora edited comment on COMPRESS-500 at 1/28/20 11:22 AM: ---------------------------------------------------------------- [~bodewig], I've got approval to share zip file with you. Can you tell how can I share it with you? The file size is around 347MB. Meanwhile I'm sharing split files the zip here, you can get the complete zip file by running {code:java} cat invalidzip.zip.part* > invalidzip.zip.part.zip {code} was (Author: anveshmora): [~bodewig], I've got approval to share zip file with you. Can you tell how can I share it with you? The file size is around 347MB. Meanwhile I'm sharing part files on this JIRA, you can get the complete zip file by running {code:java} cat invalidzip.zip.part* > invalidzip.zip.part.zip {code} > 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)