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.
For those who are unaware, there is another project [1] that tracks upstream which adds support for various codecs like Zstandard. Many folks (such as myself) opt to install their releases instead.
Perhaps a tangent, but until now, I've only seen or used "codec" in the audio/video sense. While somehow awkward, it seems this would also be correct, since it also compresses and decompresses. Video codec but archive format.
Sometimes you see a word used a new way and wonder if you've just been wrong all these years.
Rare for people who don't deal with encoding and decoding maybe.
To be clear the codec implements the compression (or other encoding) algorithm. So when talking about codec's we mean the implementation. But when talking about the algorithm, we are talking about the standard of encoding the encoder or decoder implements.
There is also NanaZip which aims to be a more modern Windows application and I think also incorporates the additions of the 7zs fork https://github.com/M2Team/NanaZip
7-Zip 15.05 is still useful today, because it was the last version to include built-in support for decompiling NSIS installer scripts. The feature was removed due to security concerns.
Windows has shipped with "ZIP folders" and the ability to create and extract ZIP files since the late 90s/early 2000s I believe (not sure exactly what version.) As of the latest versions of Windows 11, Windows ships with libarchive-based archive extraction, which should let you extract many archives natively (including 7-zip and RAR) via the UI as well as the CLI (via BSD TAR, which also ships with Windows these days.)
ZIP Folders was developed by Dave Plummer from Microsoft (who runs the Dave's Garage YouTube channel). It was made in his spare time, then was licensed to Microsoft afterwards.
Is there any proof that any version of windows shipped his implementation? Because many things that scammer (like literally he ran a pc tech support scam company) says have little to no relation to reality
Why not? It's probably the most used archiver in history. It may not be the greatest technical marvel but it was well enough liked in its day (it has been fully replaced in newer versions).
They were introduced in the Microsoft Plus package for Windows 98, then finally integrated into Windows ME. Windows ME was released after Windows 2000, so the feature didn't appear there. But it did appear in XP. You could actually install the Windows ME version of the shell extension on 2000.
Ah, well that might explain my thinking it came around in the XP days - by then I had discovered the WinRAR indefinite trial, so I didn't really need an alternative.
it goes much further back than that, think it was xp
the issue is that it sucks, it's at least 10x slower than 7 zip, maybe more, showing lots of files/folders freezes the explorer gui on w10 and it only supports .zip (which could've been changed on w11, never used, never tried)
It does ship with one, right click on zip file -> extract all. Why are you posting incorrect information that would have been clarified to you by a 3 second google search beforehand?
It didn't ship in the distant past due to anti-competitive reasons but it is there now.
I think you're talking about the extraction feature that came with ZIP folders. Aside from being clunky it's also rather inefficient and slow, it doesn't have any provisions for handling issues like mojibake, and is generally just not very robust. So why? AFAIK it's because the ZIP Folders/Visual ZIP code was basically integrated with Windows and then never updated. When it shipped in Windows XP (and possibly earlier, but I don't remember for sure) I think it was perfectly serviceable... it just didn't improve much over time.
I can't really stomach Windows 11 so I don't personally use it but my understanding is that the latest version of Windows 11 has finally integrated a better solution, implementing archive extraction based on libarchive.
Terrible how? It just needs to zip and unzip and it does that fine for most users. What else do you expect for casual users? For power usurers there's 7zip or WinRar or other solutions.
> Maybe I should say, why does the Windows unarchiving feature suck?
And what stopped you from saying that? HN rules say comments should be in good faith. What you said has clearly different meaning than what you say you meant.
When it has bad support for just zip I think phrasing it as windows lacking an unarchiving utility is reasonable enough, and certainly not bad enough to get flagged like the comment currently is. It's not bad faith, jeez. I'm going to go vouch for the comment and hope it survives.
And it's only because of that comment that I learned windows 11 finally improves things.
HN users are different breed of sticklers that aren't representative of the norm.
There's a grand canyon gap between something not existing and you not liking it how it works because your personal tastes, hence why the comment is flagged, because it's in bad faith and disingenuous.
> HN users are different breed of sticklers that aren't representative of the norm.
It acts kind of like a folder but tons of things don't work when you navigate into it. And it hasn't been improved in 20 years. It's bad.
It's significantly worse for a random person because stuff breaks and they don't know why. At least if you try to run an exe it asks about extracting the whole thing so that one case is less likely to blow up.
> There's a grand canyon gap between something not existing and you not liking it how it works because your personal tastes, hence why the comment is flagged, because it's in bad faith and disingenuous.
Just the fact that it doesn't work for any other archive format is enough to make the original comment merely sloppy wording. It's not bad faith or disingenuous. Don't be so judgemental.
It does, but it's annoying because it treats things as folders, which I suppose is nice if you just want to look inside the zip, but a pain if you just want to extract something in a normal way like you'd do with any other unzipping utility.
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.
Gnome's file-roller can do this. Not sure if it can run on Windows though.
https://wiki.gnome.org/Apps(2f)FileRoller.html
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.
I just tried it with 7-zip 19.0, and double-clicking a video file in a 7z archive, and VLC could not open the extracted file because it didn't exist.
E: Tried again with procmon monitoring 7-zip, and after it completed writing the file it deleted it.
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.
how is that possible?
tar.gz files don't have a central directory (like zip), and they are compressed as one stream (almost always non-seekable)
.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.
Decompress, scan as you go, discard. Having to read a few hundred GB and scan a terabyte is a nuisance. Not having to write a terabyte is priceless.
Could also maintain an in-memory index so that you can go back after the fact and extract individual files.
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.
I am guessing the gzip is retrieved as a stream and then reading the tar from that stream in memory?
For those who are unaware, there is another project [1] that tracks upstream which adds support for various codecs like Zstandard. Many folks (such as myself) opt to install their releases instead.
[1]: https://github.com/mcmilk/7-Zip-zstd
I prefer NanaZip[1]. It has all the features of the ZS and NSIS fork while being fully compatible with the new Windows context menus.
[1]: https://github.com/M2Team/NanaZip
Perhaps a tangent, but until now, I've only seen or used "codec" in the audio/video sense. While somehow awkward, it seems this would also be correct, since it also compresses and decompresses. Video codec but archive format.
Sometimes you see a word used a new way and wonder if you've just been wrong all these years.
The defining factor isn't compression/decompression, it's just encoding.
You'll see codec used in things like text encoding.
While technically true, the term has been largely co-opted by the A/V realm. It’s pretty rare to hear outside of the context.
Rare for people who don't deal with encoding and decoding maybe.
To be clear the codec implements the compression (or other encoding) algorithm. So when talking about codec's we mean the implementation. But when talking about the algorithm, we are talking about the standard of encoding the encoder or decoder implements.
> Rare for people who don't deal with encoding and decoding maybe.
No, rare in general.
It's a layman's co-opting, and laymen outnumber specialists in every field.
You commonly encounter the term when you want to do bytes to string conversions and vice versa on Python: https://docs.python.org/3/library/codecs.html
Note that the official 7z build supports zstd compression since version 24: https://github.com/ip7z/7zip/releases/tag/24.05
Only decompression, not compression.
There is also NanaZip which aims to be a more modern Windows application and I think also incorporates the additions of the 7zs fork https://github.com/M2Team/NanaZip
Maybe it's just me but I got weird feelings seeing 7-Zip-zstd repo having more stars than it's upstream.
Github is just a mirror used to post sources of releases and track bugs. It has only 11 commits so far.
7-Zip 15.05 is still useful today, because it was the last version to include built-in support for decompiling NSIS installer scripts. The feature was removed due to security concerns.
I've not personally used it, but there's a fork that adds NSIS decompilation back in: https://github.com/myfreeer/7z-build-nsis
Why is decompiling NSIS a security concern?
In case of bugs in the decompiler. Extracting the files is still possible in newer versions, just not decompiling the installer scripts.
what is NSIS?
Nullsoft Scriptable Install System, a byproduct of Winamp that is ubiquitous in lightweight software installers for Windows.
https://sourceforge.net/projects/nsis/
Is there an alternative version for Linux?
I wish either RAR or 7-Zip would finally implement a memory-hard KDF for encrypted archives.
Lately I use zstd + tar for making archives that preserve file metadata.
I don’t know why we need this now because Microsoft had in build zip so
Because that one is rubbish, and this is gold.
Why doesn't Windows ship with an unarchiving utility?
Windows has shipped with "ZIP folders" and the ability to create and extract ZIP files since the late 90s/early 2000s I believe (not sure exactly what version.) As of the latest versions of Windows 11, Windows ships with libarchive-based archive extraction, which should let you extract many archives natively (including 7-zip and RAR) via the UI as well as the CLI (via BSD TAR, which also ships with Windows these days.)
ZIP Folders was developed by Dave Plummer from Microsoft (who runs the Dave's Garage YouTube channel). It was made in his spare time, then was licensed to Microsoft afterwards.
Is there any proof that any version of windows shipped his implementation? Because many things that scammer (like literally he ran a pc tech support scam company) says have little to no relation to reality
>ZIP Folders was developed by Dave Plummer from Microsoft
I'm not sure I'd tell people I did that if it were me.
Why not? It's probably the most used archiver in history. It may not be the greatest technical marvel but it was well enough liked in its day (it has been fully replaced in newer versions).
I think those first appeared in some form in XP. I don't recall 2000 having support for it integrated into explorer.
They were introduced in the Microsoft Plus package for Windows 98, then finally integrated into Windows ME. Windows ME was released after Windows 2000, so the feature didn't appear there. But it did appear in XP. You could actually install the Windows ME version of the shell extension on 2000.
Ah, well that might explain my thinking it came around in the XP days - by then I had discovered the WinRAR indefinite trial, so I didn't really need an alternative.
In October of 2023 Windows 11 was updated to use libarchive https://www.techspot.com/news/100663-windows-11-extends-supp...
I think that at least since win10 there is zip embedded in windows, it’s just not 7z
it goes much further back than that, think it was xp
the issue is that it sucks, it's at least 10x slower than 7 zip, maybe more, showing lots of files/folders freezes the explorer gui on w10 and it only supports .zip (which could've been changed on w11, never used, never tried)
Zip support has been in Windows since XP.
In 11 (and maybe later 10 updates) they added 7z and rar support.
Except weirdly enough, when you open a .zip there is an "Extract All" button.
When you open a .tar.gz or a .rar that button is gone.
For those you need to do right mouse on the .tar.gz or .rar and click "Extract All...".
I miss the days when Windows' UI was consistent.
I don't think windows UI has ever been consistent after the second release.
It's just more noticeable on 11/10 because the last four releases each have a very distinct visual style.
It does ship with one, right click on zip file -> extract all. Why are you posting incorrect information that would have been clarified to you by a 3 second google search beforehand?
It didn't ship in the distant past due to anti-competitive reasons but it is there now.
It doesn't ship with a working unarchive utility, the one that is included will discard anything that goes over the maximum pathname length.
It also tends to kill explorer any time you try to decompress anything you'd actually compress in the first place (ie 100gb of json or a db dump)
Weird, I never ran into that issue. Am I holding it wrong?
It ships with a very terrible wizard. Maybe I should say, why does the Windows unarchiving feature suck?
I think you're talking about the extraction feature that came with ZIP folders. Aside from being clunky it's also rather inefficient and slow, it doesn't have any provisions for handling issues like mojibake, and is generally just not very robust. So why? AFAIK it's because the ZIP Folders/Visual ZIP code was basically integrated with Windows and then never updated. When it shipped in Windows XP (and possibly earlier, but I don't remember for sure) I think it was perfectly serviceable... it just didn't improve much over time.
I can't really stomach Windows 11 so I don't personally use it but my understanding is that the latest version of Windows 11 has finally integrated a better solution, implementing archive extraction based on libarchive.
>It ships with a very terrible wizard.
Terrible how? It just needs to zip and unzip and it does that fine for most users. What else do you expect for casual users? For power usurers there's 7zip or WinRar or other solutions.
> Maybe I should say, why does the Windows unarchiving feature suck?
And what stopped you from saying that? HN rules say comments should be in good faith. What you said has clearly different meaning than what you say you meant.
When it has bad support for just zip I think phrasing it as windows lacking an unarchiving utility is reasonable enough, and certainly not bad enough to get flagged like the comment currently is. It's not bad faith, jeez. I'm going to go vouch for the comment and hope it survives.
And it's only because of that comment that I learned windows 11 finally improves things.
Who's the judge of zip support being 'bad'?
HN users are different breed of sticklers that aren't representative of the norm.
There's a grand canyon gap between something not existing and you not liking it how it works because your personal tastes, hence why the comment is flagged, because it's in bad faith and disingenuous.
> Who's the judge of zip support being 'bad'?
> HN users are different breed of sticklers that aren't representative of the norm.
It acts kind of like a folder but tons of things don't work when you navigate into it. And it hasn't been improved in 20 years. It's bad.
It's significantly worse for a random person because stuff breaks and they don't know why. At least if you try to run an exe it asks about extracting the whole thing so that one case is less likely to blow up.
> There's a grand canyon gap between something not existing and you not liking it how it works because your personal tastes, hence why the comment is flagged, because it's in bad faith and disingenuous.
Just the fact that it doesn't work for any other archive format is enough to make the original comment merely sloppy wording. It's not bad faith or disingenuous. Don't be so judgemental.
>Just the fact that it doesn't work for any other archive format
Humor me, how popular or other non-zip formats for average Joe's uses?
I'm a paper user and can't remember the last time I encountered a non zip format.
I'm not sure but I've sure seen a lot of winrar memes.
I guess that settles it.
The Extraction Wizard is a bit clunky opening a dialog box asking where you want to extract things...
...then a brief flash as the decompress happens because it's no longer 1998 and we're not extracting 2 MB of ZIP files on a Pentium 166,
... then you get a silly "complete!" screen with a pre-filled checkbox that spawns another Windows Explorer window by default.
Eh, three clunky "wizard" screens is a bit much for a "extract here..." command.
That never bothered me. That's a non issues for normal people.
It does, but it's annoying because it treats things as folders, which I suppose is nice if you just want to look inside the zip, but a pain if you just want to extract something in a normal way like you'd do with any other unzipping utility.
I wish there were an easy way to get Explorer not to show Zip files as a "folder." Such a huge anti feature for me.