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?
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:
ACVS
3.1.3.5
SerialisableProjectData
json
Linux
{
“data”: {
“version”: 5,
It decompresses up the first { and then stops. Most strange.
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.
thx for both suggestions.
