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

        

Mime
View raw message