[COMPRESS-500] Discrepancy in file size extracted using ZipArchieveInputStream and Gzip decompress component

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Not A Bug
• Affects Version/s: 1.8, 1.18
• Component/s: Compressors
• Assignee: Unassigned
• Reporter: Anvesh Mora
• Created: 16/Dec/19 06:10
• Updated: 02/Feb/20 12:47
• Resolved: 02/Feb/20 12:47

Description

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!