Re:Micro-Optimizing .tar.gz Archives by Changing File Order
by pornel on Thursday August 20, 2020 @08:10AM
(#24222382)
There's no simplicity in tar. Even reading the file size is a guesswork. It's a baroque format with weird short-sighted decisions patched and extended in ad-hoc ways by multiple subtly incompatible implementations.
Re:Micro-Optimizing .tar.gz Archives by Changing File Order
by klodolph on Thursday August 20, 2020 @08:15AM
(#24222414)
Unless you're using PaX, isn't the file size just a fixed-size field in the header? Is there something I'm missing?
Re:Micro-Optimizing .tar.gz Archives by Changing File Order
by Hello71 on Thursday August 20, 2020 @08:37AM
(#24222571)
fixed... ish... with two sizes and two formats: https://dev.gentoo.org/~mgorny/articles/portability-of-tar-f...
Re:Micro-Optimizing .tar.gz Archives by Changing File Order
by pdw on Thursday August 20, 2020 @09:50AM
(#24223190)
It's unix philosophy alright, but it's the other unix philosophy -- worse is better. tar has a poorly designed base format with lots of incompatible extensions, but for most people most of the time it works fine. So why change?
Re:Micro-Optimizing .tar.gz Archives by Changing File Order
by fomine3 on Monday August 24, 2020 @10:32PM
(#24267663)
Is tar "worse" in the context?
Re:Micro-Optimizing .tar.gz Archives by Changing File Order
by lifthrasiir on Thursday August 20, 2020 @08:01AM
(#24222334)
> Overall, I think it appeals to the "unix philosophy" - composing two independent tools (tar and gzip) instead of having one integrated solution.
The unix philosophy in this case breaks down when you need to access individual files. One possible "unixy" solution would be .gz.tar as opposed to .tar.gz, but it is not universally supported as .tar.gz is.
Re:Micro-Optimizing .tar.gz Archives by Changing File Order
by heavenlyblue on Thursday August 20, 2020 @08:08AM
(#24222369)
You can have the first file in the tar archive as the "index" file
The seperation of "group files into an archive" and "compress these bytes" can also be very useful. For example, it means I can play around with the latest and greatest compression formats without needing to wait for a version of tar that has that format built-in.
Overall, I think it appeals to the "unix philosophy" - composing two independent tools (tar and gzip) instead of having one integrated solution.
The "tape drive" part is legacy cruft, certainly, but in practice its removal doesn't improve things enough that people find it worth the compatability break.
I'm not going to claim this is better than the more modern feature-rich archive formats, but hopefully this helps you understand the other side of the argument a little better.