[ 
https://issues.apache.org/jira/browse/COMPRESS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17003882#comment-17003882
 ] 

Anvesh Mora commented on COMPRESS-500:
--------------------------------------

[~Peter Alfred Lee], wetransfer wouldn't work for us. I'm inquiring in the 
company what is the right tool to share across. Will let you know if any. I've 
to also plan to encrypt the data while transferring/uploading.

> 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
>
> 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)

Reply via email to