Having an issue with GZIPDecompressorInputStream

Hi, I’m trying to decompress a gzip file - opens fine in Winzip for Mac so I know it’s a valid archive.

Input file is 24016 bytes, but when I try to read from the stream, it only returns the first 48 bytes and stops.

I’m using the gzipFormat mode as the other modes both return 0 bytes.

Any ideas? thx

Any suggestions from the juce team here?

Is the file definitely in gzip format?
What does the command

file your_filename.gzip

tell you about its content?

1 Like

Empty.xpj: gzip compressed data, from Unix, original size modulo 2^32 0

I’m by no means an expert in GZIP compression. What I’d do at this point, is to check if the description given by the file command on your .xpj file is the same given for a “regular” .gz file obtained via the “gzip” command.
If they differ somehow, and the “regular” .gz file decompresses ok while your .xpj doesn’t, then I’d investigate further on that, using the different descriptions as hint for a Google search. If they match, I’d be quite out of ideas then…

good idea!

Empty22.json.gz: gzip compressed data, from Unix, original size modulo 2^32 1286506

so, looks like the xpj has specified an original file size of 0, which is probably causing the problem. Looks like things like winzip, gzip handle this case but the JUCE code doesn’t.

I guess it does beg the question why the size comes back as 48 bytes in the stream rather than 0…

this is the start of the actual content:
“data”: {
“version”: 5,

It decompresses up the first { and then stops. Most strange.

@reuk hi - anyone on the team any insight into this? thx

You’ll probably need to provide a test file to troubleshoot with.

In the meantime, what if you tried specifying a window size of MAX_WBITS | 32 (where MAX_WBITS is 15) to let zlib figure out the format?

You’ll need to hack it in by replacing getBitsForFormat (f) with the above value. This is because GZIPDecompressorInputStream uses an enumeration.

1 Like

thx for both suggestions.