CRC32 during straming gzip

[Mohun Biswas]

I have a FileOutputStream which I wrap with a GZIPOutputStream, just as
described in the documentation. Thus I'm reading uncompressed data from
a stream and writing it in compressed form. This works fine, but I also
need a CRC of the (uncompressed) data. I'd hate to have to read the data
twice, once for the CRC and then again to compress it. What I want to do
is hook a java.util.zip.CRC32 object into the "pipe" in a way that lets
it accumulate CRC data as the data streams by into the GZIPOutputStream.
Can anyone give me the rough outline of how this is done?

 

[Mohun Biswas]

Sorry, of course the subject is supposed to say "streaming gzip".

 

[Roedy Green]

Can anyone give me the rough outline of how this is done?

Check out the term filter in the java.io class.

All you have do is implement an interface, then you can plug in just
like all the other lego.

 

[Chris Uppal]

need a CRC of the (uncompressed) data. I'd hate to have to read the data
twice, once for the CRC and then again to compress it.

GZIPOutputStream maintains a crc for you, the protected java.util.zip.CRC32
field that is just about the first thing mentioned in the documentation ;-)

For some weird reason, GZIPOutputStream doesn't provide public access
to the crc, so you'll have to create, and use, a trivial subclass that does.

-- chris

 

[Roedy Green]

For some weird reason, GZIPOutputStream doesn't provide public access
to the crc, so you'll have to create, and use, a trivial subclass that does.

Would it not throw some sort of CorruptStream exception if it were
wrong. You can check by fudging a byte in a file with a hex editor.
pick a char is a data string so you wont corrupt the structure.

Doubt the CRC checks headers, just the body. Could find that by
experiment.

 

[Chris Uppal]

Would it not throw some sort of CorruptStream exception if it were
wrong.

Um, how can a gzip OUTPUT stream find a corrupt CRC ?

Doubt the CRC checks headers, just the body. Could find that by
experiment.

Or go read the documentation.

-- chris

 

[Roedy Green]

Or go read the documentation.

The documentation tells you what is SUPPOSED to do. The experiment
tells you what it does.

That is the sort of thing that could easily slip by Q&A.