Retreive time of compressed (internal) file on decompressSync

[ArndBrugman]

Hi, I really like the simple interface and the fact that it runs both in browser and on node.

I'm currently using it on a solution and have a question about retrieving the time of the file I compressed. So not the file time of the compressed file, but the internal compressed file's time I supplied when creating the gzip using:

const gzipped = fflate.gzipSync(textData, { filename: 'rawdata.dta', mtime: now, level: 6 });

That time of mtime: now, has meaning when I try inflating the data using:

const decompressed = fflate.decompressSync(zipContent);

The compression and decompression (fflate) works as expected, great. I just need a simple way to retrieve the date/time of the internal compressed file, the one I supplied when compressing the data. Is there a way to retrieve it? Do I need to switch compression or decompression maybe?

I was unable to find this in the documentation, Q&A and even studied the code.

Thanks for your time and effort, hope you can assist me with an answer.

[101arrowz]

I would suggest implementing this yourself outside of fflate; I'll send some sample code to do that later today.

[ArndBrugman]

Thx for your quick reply. It made me look at the header details of gzip, chapter 2.2 of https://www.ietf.org/rfc/rfc1952.txt

I have coded a quick solution:

            try { // Read mtime from gzip header
              if (cacheZipContent.length > 10 && cacheZipContent[0] == 0x1f && cacheZipContent[1] == 0x8b) { // gzip Header Length
                const mtime = cacheZipContent[4] + cacheZipContent[5] * 256 + cacheZipContent[6] * 256 * 256 + cacheZipContent[7] * 256 * 256 * 256;
                internalFile.Modified = new Date(mtime * 1000).toISOString();
              }
            } catch { }

If you have any additions or comment, I am open for suggestions and discussions.

Thx for your time and effort to put fflate to the level it is a valuable addition in my solution!

[101arrowz]

Nice, that's pretty much the same code I would've sent you (albeit using bit shifts instead of multiplication, though that does cause some issues for the most significant bit of 32-bit unsigned integers). Definitely seems reasonable.