[
https://issues.apache.org/jira/browse/COMPRESS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anvesh Mora updated COMPRESS-500:
---------------------------------
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.
was:
Recent time I raised a bug facing a issue of "invalid Entry Size" COMPRESS-494.
File Structure:
In Zip file
We have zero or more gz files which need to decompressed
And meta data used for 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.
> Discrepancy in file 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.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
