hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom White (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-8522) ResetableGzipOutputStream creates invalid gzip files when finish() and resetState() are used
Date Thu, 21 Jun 2012 21:13:43 GMT

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

Tom White commented on HADOOP-8522:
-----------------------------------

The patch looks good to me. A small suggestion regarding the test: why not use GzipCodec to
decompress too? Then you can have an assert in the test, and it checks roundtripping using
Hadoop APIs. 

> That may be one reason this bug has lain dormant for so long with the non-native implementation
(serious users tend to use the native libs).

Also, Hadoop has only supported concatenated gzip since HADOOP-6835, so files that had corrupt
later members would have been ignored by versions of Hadoop prior to this.

                
> 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
>         Attachments: HADOOP-8522-2a.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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message