(In reply to Mike Conley (:mconley) (:⚙️) from comment #4) > So here's a thought - I believe a `CompressionStream` would let me compress a single stream of bytes down off of the main thread. What if I use the `nsIZipWriter` at COMPRESSION_NONE to archive all of the various backup files into a single uncompressed file, and _then_ run it through a CompressionStream before sending it down to be written into the single-file archive. So I'd basically be using `nsIZipWriter` to just... `tar` the files up. It'd be a `.zip.gzip` archive. Kinda hilarious. Ugly but yes that would work. > Alternatively, we could modify nsIZipWriter to deflate off of the main thread, but that sounds pretty annoying and error-prone. > > We could also potentially introduce a new off-main-thread zipping mechanism. It looks like we already vendor in the `zip` Rust crate: https://searchfox.org/mozilla-central/rev/4c8627a76e2e0a9b49c2b673424da478e08715ad/Cargo.toml#190-191. This would, however, likely make backporting the backup mechanism to 115 more challenging. Neither of these options sounds compatible with uplifting to 115, and the zip crate isn't async anyway so you'd still have to figure out threading too. There is another option that I think would work. Add a new method to `nsIZipWriter`, something like `addCompressedFile`. It should behave like `addEntryFile` when `COMPRESSION_NONE` is passed but set the zip entry header's method field to `ZIP_METHOD_DEFLATE`. Then for the files you give it pass their data through a `CompressionStream` first, I think using the `deflate-raw` compression. Essentially do the compression for each file yourself, then have `nsIZipWriter` just store that data but mark it as compressed so it is handled correctly when extracting.
Bug 1898785 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Mike Conley (:mconley) (:⚙️) from comment #4) > So here's a thought - I believe a `CompressionStream` would let me compress a single stream of bytes down off of the main thread. What if I use the `nsIZipWriter` at COMPRESSION_NONE to archive all of the various backup files into a single uncompressed file, and _then_ run it through a CompressionStream before sending it down to be written into the single-file archive. So I'd basically be using `nsIZipWriter` to just... `tar` the files up. It'd be a `.zip.gzip` archive. Kinda hilarious. Ugly but yes that would work. > Alternatively, we could modify nsIZipWriter to deflate off of the main thread, but that sounds pretty annoying and error-prone. > > We could also potentially introduce a new off-main-thread zipping mechanism. It looks like we already vendor in the `zip` Rust crate: https://searchfox.org/mozilla-central/rev/4c8627a76e2e0a9b49c2b673424da478e08715ad/Cargo.toml#190-191. This would, however, likely make backporting the backup mechanism to 115 more challenging. Neither of these options sounds compatible with uplifting to 115, and the zip crate isn't async anyway so you'd still have to figure out threading too. There is another option that I think would work. Add a new method to `nsIZipWriter`, something like `addCompressedFile`. It should behave like `addEntryFile` when `COMPRESSION_NONE` is passed but set the zip entry header's method field to `ZIP_METHOD_DEFLATE`. Then for the files you give it pass their data through a `CompressionStream` first, I think using the `deflate-raw` compression. Essentially do the compression for each file yourself, then have `nsIZipWriter` just store that data but mark it as compressed so it is handled correctly when extracting. Sort of similar to your first suggestion, but you end up with a normal zip file.