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] [Resolved] (HADOOP-6799) GzipCodec/CompressionOutputStream resetState() fails to reset gzip header and CRC
Date Fri, 22 Jun 2012 20:00:43 GMT

     [ https://issues.apache.org/jira/browse/HADOOP-6799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Tom White resolved HADOOP-6799.

    Resolution: Duplicate

This is being fixed in HADOOP-8522.
> GzipCodec/CompressionOutputStream resetState() fails to reset gzip header and CRC
> ---------------------------------------------------------------------------------
>                 Key: HADOOP-6799
>                 URL: https://issues.apache.org/jira/browse/HADOOP-6799
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: io
>    Affects Versions: 0.21.0
>         Environment: Linux/x86-32, Java 1.6.0_15
>            Reporter: Greg Roelofs
>            Priority: Minor
>     CompressionCodec gzip = new GzipCodec();
>     Path fnHDFS = new Path(workDir, "concat" + gzip.getDefaultExtension());
>     OutputStream out = localFs.create(fnHDFS);
>     Compressor gzCmp = gzip.createCompressor();
>     CompressionOutputStream gzOStm = gzip.createOutputStream(out, gzCmp);
>     gzOStm.write("first gzip concat\n member\nwith three lines\n".getBytes());
>     gzOStm.finish();
>     gzOStm.resetState();
>     gzOStm.write("2nd gzip concat member\n".getBytes());
>     gzOStm.finish();
>     gzOStm.resetState();
>     gzOStm.write("gzip concat\nmember #3\n".getBytes());
>     gzOStm.close();
> This should create a 3-member concatenated gzip file (i.e., equivalent to concatenation
of three individual gzip files).  However, resetState() simply resets the underlying deflate
engine; it does not reset the running CRC-32, nor does it set a flag to write a new gzip header.
 As a result, the output stream is corrupted--i.e., only the first member is readable.
> I also have hex dumps, but they don't work well with proportional fonts.

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


View raw message