[
https://issues.apache.org/jira/browse/HADOOP-8522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16241410#comment-16241410
]
Mike Percy commented on HADOOP-8522:
------------------------------------
[~chris.douglas] Overall the changes look good to me. [~fabbri] do you have any
additional thoughts on this? You took a look at rev 4 from me some time back.
One thing that caught my eye was the decision to make the methods out the
GZipOutputStream synchronized. If the contract for CompressionOutputStream is
not thread safe it seems like overkill.
> ResetableGzipOutputStream creates invalid gzip files when finish() and
> resetState() are used
> --------------------------------------------------------------------------------------------
>
> Key: HADOOP-8522
> URL: https://issues.apache.org/jira/browse/HADOOP-8522
> Project: Hadoop Common
> Issue Type: Bug
> Components: io
> Affects Versions: 1.0.3, 2.0.0-alpha
> Reporter: Mike Percy
> Assignee: Mike Percy
> Labels: BB2015-05-TBR
> Attachments: HADOOP-8522-4.patch, HADOOP-8522.05.patch,
> HADOOP-8522.06.patch, HADOOP-8522.07.patch
>
>
> ResetableGzipOutputStream creates invalid gzip files when finish() and
> resetState() are used. The issue is that finish() flushes the compressor
> buffer and writes the gzip CRC32 + data length trailer. After that,
> resetState() does not repeat the gzip header, but simply starts writing more
> deflate-compressed data. The resultant files are not readable by the Linux
> "gunzip" tool. ResetableGzipOutputStream should write valid multi-member gzip
> files.
> The gzip format is specified in [RFC
> 1952|https://tools.ietf.org/html/rfc1952].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
