gzip: Correctly handle multiple members #795
Conversation
|
Looks good. |
868cbdc to
d305ccc
Compare
|
Are you sure the other testdata changes are ok? In format/gzip/testdata/compressed_size.fqtest and format/json/testdata/tofromjson.fqtest, is it intentional that the test doesn't show what's inside the gzip anymore? In format/zip/testdata/test0.fqtest etc, why does the local_files entry for |
A gzip file consists of one or more "members" that are concatenated on uncompress. Introduce a members array with each member and uncompressed is now the concatenation. Fixes #794
d305ccc to
ac276ee
Compare
Nope :) I thought so but i was a bit too quick, fixed. Thanks! some weirdness in the output i think 8000 was caused by that the gzip decoder succeeded for an empty input. Now i've remodelled so that the root is a struct again and then there is a "members" array and the root "uncompressed" is the concat of the member uncompressed. You can still access each member uncompress as What do you think? i'm still not very happy with the uncompress related code in fq, is a bit of a mess, but have not found good abstraction yet to make it more shareable between compression formats. |
|
I haven't reviewed the go code, but the output looks good. 👍 |
|
Ok, thanks! i'm still not very happy with the most of the archive decoders in fq but that is for a future PR. Ex user facing-wise it would be nice if all of them had common |
A gzip file consists of one or more "members" that are concatenated on uncompress.
Introduce a members array with each member and uncompressed is now the concatenation.
Fixes #794