Hacker News Reader

Comment by koolba | Hacker News Reader

> Fortunately, we can fix the fact that tar.gz files are unindexed and unseekable, while still making the file a valid tar.gz file by taking advantage of the fact that two gzip streams can be concatenated and still be a valid gzip stream. So you can just make a tar file where each tar entry is its own gzip stream.

I'm surprised nobody came up with this idea till now. It's brilliantly simple.

View on HN

> This makes images a few percent larger

Teehee. The method is not new at all, for example compressors like xzip do this out of the box, and almost the exact thing they're doing is basically how ZIP files work

The trouble with discarding state on every file is that it really hurts performance with small files, or when using anything like a modern codec, which gzip/deflate is not. Gzip maintains a 32kb dictionary which is quite easy to exceed with contemporary data, but with a modern compressor (like lzma2) losing that window will absolutely devastate ratios

The usual solution is so-called 'solid' compression, where the uncompressed input is partitioned into blocks spanning file boundaries. It configurably trades seek efficiency for reliably preserving compressor context -- including allowing seeking within files. Their format could be modified to support this while retaining backwards compatibility as good as the current method. What they have is already pretty much solid compression, except it only chunks large files. This is basically a weird special case of a simpler and more general design everyone else uses.

Finally on the compatibility angle, the end of stream is visible at an API level, so this isn't going to be 100% perfect. I'd expect one or more obscure implementations (maybe Windows apps? Java?) to potentially break

Well, for one, it's not obviously useful in traditional applications:

> This makes images a few percent larger (due to more gzip headers and loss of compression context between files), but it's plenty acceptable.

Compressing an entire image is generally great. Compressing all of the individual files in an image, is generally not great.

Maybe not great, but like I said: acceptable.

About 7.6% bigger: https://github.com/golang/build/commit/8a5a4d227f08eb1d889fa...

That's what I meant by "brilliantly simple"; namely having something like this work with existing systems while imposing a marginal overhead.

Compressing individual files would probably result in a bigger file, ofc depending on the content mostly.

dict uses something similar:

https://linux.die.net/man/1/dictzip

Reply on news.ycombinator.com