I wish 7-zip would support .tar.gz the way WinRAR does.
WinRAR allows you to browse a .tar.gz without extracting it, 7-zip extracts the .tar to a temp file. It makes working with large .tar.gz files impossible.
(Yes I know that because of how .tar works WinRAR must decompresses it to build the files list. But it beats having to write a 1TB .tar to disk just to see the file listing.
WinRAR also seems to handle opening a file in an external app without manually extracting much better. I can just double-click a file in an archive and open it in an external app, while with 7-zip it seems to immediately delete the temporary file so the external app ends up trying to open a non-existent file. Rather annoying if you're just trying to quickly check something like the readme.txt in an archive.
>while with 7-zip it seems to immediately delete the temporary file so the external app ends up trying to open a non-existent file.
No, 7-zip only deletes the file after you close its window, so as long as you don't close 7-zip any apps should be able to open those files. Winrar doesn't delete on close, but that has its own problems, namely that you accumulate a bunch of extracted files in your %TEMP% directory, and have to run disk cleanup to delete them.
There must be something funky with your setup. I just tested using the exact version of 7-zip and latest version of VLC in a fresh windows VM, and it doesn't have you issue you described. I can even see the file lying around in %TEMP%\7z[random characters], and they aren't deleted until I close the 7-zip window.
.tar itself gives you enough information to seek forward past each file, though every file must be visited.
.gz does not give you enough information to randomly seek within the big compressed .gz file, so you cannot skip past files within a .tar archive.
But if you load a .gz file and consume the entire stream, but keep periodic checkpoints of your past sliding window (about 64KB) every 1MB or so, you can get random access with 1MB granularity. You still had to consume the entire stream to build the lookup though.
That's less helpful than you might imagine - gzip isn't seekable by default; if all you know is the seek point, you still have to decompress everything up to that point to start decompressing from there. And if you have to do that, reading the tar headers as you go isn't a serious burden.
What might help is saving the state of the decompressor periodically, rather than just the index in the file. But that's getting pretty far into the weeds for an optimization to an infrequently used feature.
Interesting, yeah that makes sense— and I agree, that would be tricky to figure out the proper balance of caching the actual contents somewhere vs just caching the decompressor state, and whether that caching goes to RAM or disk. There isn't an obvious right answer for either, nor is there necessarily a right way to expose that option to the user.
Can definitely see why systems like python's wheel would choose zip as it's just always been natively seekable out of the box. I believe Nix now does something similar with flake repo archives being zipfiles in the store, as they can be seeked and evaluated without a full decompression, saving a lot of disk space.
WinRAR allows you to browse a .tar.gz without extracting it, 7-zip extracts the .tar to a temp file. It makes working with large .tar.gz files impossible.
(Yes I know that because of how .tar works WinRAR must decompresses it to build the files list. But it beats having to write a 1TB .tar to disk just to see the file listing.