Not in GZIP format error while trying to unzip the file

Question

I'm using GZIPInputStream in order to read data from zipped file.
It worked perfectly from command line. I have to execute the same code from crontab and it gave me the exception:
java.io.IOException: Not in GZIP format
It tries to check the GZIP_MAGIC number and for some reason failed.
The stack trace I'm getting points to GZIPInputStream constructor.
GZIPInputStream input = new GZIPInputStream( new FileInputStream( fileName));
Any help will be highly appreciated.
Thanks,
Arnold

Answer 1

This may be a little late for you, but I am having the same problem. I am using an encryption package as well. I created input and output streams to wrap my encryption package. (javax.?? has something similar)
Anyway, my algorithm goes: data -> gzip -> encrypt --------- ->decrypt -> gzip ->data
If I used encryption without the gzip everything works fine, and if I use gzip without the encryption it works fine as well. But if I use them in conjuction, bad thing happen.
I copied versions of the GZIPInput and output stream classes from java.util.zip and made my own so I could put in debug code. Then I saw what was happening. GZIP writes a header of 8b1f. It does this by writing a first to 1f as a byte (this is 31 in decimal) and then the 8b (this is 139 unsigned byte or -117 signed byte).
My debug code shows that it writes 31,-117 to the stream, but reads 31,139 when I don't use encryption and 31,-117 when I do. Another strange thing about this, though, is that everywhere I have debug code, this is the only byte that prints out unsigned in my debug messages... When encryption is turned on this same debug message prints -117.
I have no idea why this is happening. To test things some more, I changed my copy of the gzipinputstream to compare this header value with the GZIP_MAGIC number (35615) and with -29921. Now everything works perfectly. There has to be a better solution for this, but I don't know what it is yet.
GZIP_MAGIC is 8b1f sent as two bytes 1f and then 8b, and then shifting the 8b.
-117, using the Integer.toString(-117,16), gives a hex of -75. Using the same methodology as above, we can get -751f which is -29921.
The header check is essentially:
if ((int)readUByte(in) << 8) | (int)readUByte(in) != GZIP_MAGIC)
your screwed
So change this store the value in a variable and compare it to GZIP_MAGIC and -29921 and your problem will disappear.
I am not sure what they were thinking. readUByte is a simple read. There is nothing unsigned about it. There is probably some casting somewhere along here that is causing the error, but nothing I am doing seem incorrect.
Hope this helps. Actually, I hope you have solved your problem by now, but if not,... If you have any insights, I would appreciate hearing them.