[QuantumNomad_]

You can achieve the same with tar if you individually compress the files before adding them to the tar ball instead of compressing the tar ball itself.

I don’t see how that plus a small index of offsets would be notably more or less work to do from using a zip file.

[chungy]

Zip has a central directory you could just query, instead of having to construct one in-memory by scanning the entire archive. That's significantly less work.

[QuantumNomad_]

I mean if they include a pre-made index with it. For example an uncompressed index at byte offset 0 in the tar ball that lists what is inside and their offsets. It would still be comparable amount of work to create software to do that with tar as to use a zip file, if fine grained compression levels etc is being used.

[johannes1234321]

But then you are not using tar, you are doing your own file format atop of tar.

[QuantumNomad_]

I suppose you are right about that. But it would still be a valid tar file that can be viewed and extracted with normal tools. Kind of similar to how a .docx file can be extracted as zip but still has additional structure to its contents.

[chungy]

What are you really proposing? That a first ".INDEX" entry be made that contains the offsets of all the other members?

That could work in a backwards-compatible way (as long as no standard tar utility makes modifications to the archive...), but it's hamfisted. Just use Zip. It's already a well-known format with numerous implementations and already does the job that you want to do.