I spent some time a year ago comparing formats, and ended up liking pixz the most, especially being indexable. EXCEPT that according to my notes, I couldn't find any gui archiver that worked with it. Do you know if it is still that way?
I have noticed that 7-zip offers the best compression ratio out of the options you listed above when set for maximum compression. I personally am happy to hear this news.
And what's the difference?
I alwasy though 7zip was a bit sketchy like rar archives, zips are more common on windows and on linux everywhere I see there are either gz, bz2 or xz.
xz doesn't have BCJ2 (though it does have an earlier BCJ filter), which allows for somewhat better compression of exes. BCJ2 produces separate streams which independently compress better. See for instance https://bugzilla.mozilla.org/show_bug.cgi?id=1514357, saves almost 10% on a Firefox installer (which uses 7-Zip) vs the complete update .mar file (which uses xz/liblzma).
I like the current bsdtar-- it's libarchive [1] based, and supports a bunch of formats (including your typical tarball formats, but also zip, 7zip, and rar archives, amongst others).
tar supports xz and even zstd now, but it's not clear those are better for all purposes than 7zip, especially since .7z is more likely to work on other OSes than .tar.compressionextension
I'm assuming it's because 7-zip (1) has widespread use on other platforms (2) supports solid compression and (3) is efficient for randomly access. There is DAR which does (2) and (3) but not cross-platform and is already esoteric on *nix platforms.
> And developer of p7zip port didn't show any activity last 4-5 years.
I guess that would be why. I, too, assumed we had an actively maintained Linux port, but if the maintainer isn't doing much these days, a version closer to upstream would be great.
The 7zip author by his own admission does not use Linux, though, so I'd be curious if p7zip might actually be more performant on Linux.
I don't know the answer to your question, just adding that you can work around that by using tar to preserve ownership, permissions, extended attributes, selinux contexts, then use 7zip on that tar file. This can all be done in pipes in one command line.
Even considering that this is for linux, I still get pretty sad whenever I see windows users running winrar. 7-zip is simpler to use, (mostly) as fast and as compressed as rar. I really see no reason windows users still use winrar.
Companies tend to use it and buy new licenses due to the same inertia you mentioned. Although the more cost conscious will at some point switch to the free alternatives.
Educate them if you can. Whenever I see someone using crapware like bandicam I give them a link to OBS Studio and briefly describe its advantages. Same for winrar and 7zip. They usually don't know any better and were using whatever everyone else was using.
Back in the day, one of the selling points of the RAR format was that it could partition large files into multiple archives, so you could upload it in chunks, or copy it to multiple flash drives or CDs. Have other archive formats caught up with this feature?
tar was designed for tape, so you can specify a volume size for the output and it will break it's output into segments of that size. Using split isn't required.
The options in gnu tar are -L and -M for specifying tape length (in KB) and creating multi-volume archives.
The -L version is handy as it can prompt you to change the "tape". It has built-in tape handling as well, if you are using a real tape that can be controlled via mt.
Apparently (just checked info) it supports an arbitrary command to execute at the end of each archive. That would be handy for burning CDs, though I don't remember that feature from when I used floppies or QIC-40 to move files from one machine to another.
Around 1991-ish I would use these options to put archives onto stacks of floppy disks. The floppies didn't have a filesystem, just blocks of tar archive. In the days of 9600 bps modems, this was often the fastest way to move stuff to another machine. I had an often-reused stack of 3.5in HD floppies labeled with numbers for this purpose.
I was about to reply a little snarkily that I was doing this with zip archives on floppy disks back in the 90s. I thought I might as well check my facts before posting, and it looks like that was a part of WinZip that was not part of the standard.
In 2015 ISO published a standard pertaining to zip archives, and one of the specifications was (from Wikipedia):
Archives may not span multiple volumes or be segmented.
There are also multiple forum posts when you search for multipart zip archives of Linux users asking how to decompress them, suggesting that this is only WinZip behaviour and not common to the zip standard.
I had the same reaction, but checked a different set of facts than you did. PKZIP 2.04g (which at the time was the standard) supported split archives, in January 1993. WinZip added support in version 8.1, in 2001.
Edit: I just found the page where you got your quote. Looks like ISO was deliberately defining a subset of ZIP.
I remember people using arj exactly because of that feature. Compression with arj was worse than zip but people used it because you could divide an arj archive in floppies. At the time, rar could do it too, but it only got popular later.
Isn't that just the same as splitting any file into multiple chunks? Why does the archive format have to know about it? For non-solid compression? Otherwise, any file can be split up and re-combined at the other end, unless you don't have the hard drive space to recombine it.
The only way I've seen RAR used in torrents is to package everything into one big file, and since they're usually video or audio that already has lossy compression, and since I may want to prioritize or skip certain files, it's both pointless and annoying.
WinRAR is much easier to use than 7-zip in my experience. PeaZIP is easier than both, but WinRAR still wins on the "you don't actually need to know what a zip file is" point. It's both a blessing and a curse though - I've had a couple of situations where people were running portable programs from zip files and promptly losing their work once they closed WinRAR.
The big icons make way more sense and more things have icons, the ".." line is more natural than the dedicated "dir up" button, the "create archive" dialog is more organized and its options more discoverable...
And when you run an executable from it, it (I think) unzips the whole archive, not just the file, so DLLs etc. can be loaded properly. Just saves some effort and thinking when you need it and doesn't make a difference when you don't
Never compared archivers at length, cannot speak as to the actual features. But 7z has this distinct unfinished open-source GUI tool look. That's all I remember about it. It may or may not be true that it has poor UX. But the aesthetics certainly do signal this. Personally, on Windows I used 360压缩 which seems to be a better looking winrar clone without nag screens. On Linux it's "atool -x" for extracting (there's no decent Linux file explorer, so the main selling point of archiver guis is moot too).
If this is true (and I wouldn't know because I haven't had a GUI file manager on my Linux desktop since the early 2000s), it's because GUI file managers are for casuals.
7zip is hard to learn because it's straight to the punch with no BS. Regular people don't like that stuff. They want nice visuals and receive cognitive dissonance for something they pay for.
I have vague memories that things like Shift JIS file names get scrambled? IIRC it was a case of it using the users default non-Unicode / “ANSI” codepage instead of offering a selection like Winzip apparently does.
In the extracted contents. Various assets for Unity would come with folders and file names in Japanese. 7zip would extract them without the proper names and so all relative patching would be completely messed.
In fact, unrar has been open sourced by WinRAR themselves. Or rather, they made the source available, with certain conditions, i.e. not using it to reverse engineer the rar format.
I mostly use 7zip but I've had a number of archives in the past that would simply not properly extract using 7zip and WinRAR had no issues with. 7zip is fine, however I don't see it as superior really in any notable way. I don't understand why everyone is crazy over it at this point. It's good, but so is WinRAR. Why is it sad for people to use one good program over the other when they both accomplish the same thing in about the same way? There's very little special about 7zip for typical day to day use.
I use winrar because it can add a recovery record to the file, so if the file gets corrupted some years down the line I can hopefully repair the archive. 7z cannot do this, unless you create extra par2 files next to it afterwards.
WinRAR is better as an archiving tool than 7zip. It has more features, recovery records, a much better self-extracting generator (7zip's is laughably primitive), more ways to compress files (e.g. compressing multiple folders into separate archives) and it is also much faster than 7zip when compressing. Also AFAIK it is the only that supports NTFS streams, though i'm not sure how often that is needed (but might be, e.g. for preserving the downloaded status of files).
And very annoyingly, 7zip has had for years a race condition where when you open a file inside an archive, it extracts the file in the temporary folder and then... it deletes it before the associated application manages to load it. It is hit and miss when it works - often it does, but then for some reason i haven't figured out it just deletes the file. And related to that 7zip extracts only the file you double click on, so e.g. it doesn't extract any data files an executable might need or images or subpages an HTML file may refer to.
I have both installed and in my experience WinRAR is by far the better tool when it comes to handling archives with the main exception (and the only reason i have 7zip installed) being that 7zip supports extracting from far more archive formats - including disk images (i use it all the time to extract files from VirtualBox, PCem, etc disk images and seems to support a variety of file systems too).
Yes — what 7zip has going for it is that it’s free, good format support and probably usually slightly better compression ratio. But that’s basically it. WinRAR is a very competent archiver tool where you might prefer it for many reasons. One annoyance I have with 7zip is its surprising number of non-implemented features. Just today I tried dragging a file to replace an existing and got the message “access denied”. That was like code for “not supported” because deleting the file first worked. Sometimes you do get sudden “not implemented” though for the most basic operations even after all these years.
I’m not dissing Igor Pavlov. He’s a very skilled developer as for compression format development. But he ought to get some assistance on the archiver software front.
For a while they were bundling in spyware with popular downloads, which would not have been stopped by an adblocker, and common sense would have dictated it wasn't there to begin with. They've since stopped now that the site has changed hands again, as far as I know.
About a month ago, the cross-platform product I support had a group of developers considering standardizing on 7-Zip, only to realize that p7zip - what most Linux users consider 7-Zip - is actually a 3rd party project. Had this come out a month ago, it might have actually swayed their decision.
By the way, do people use unar? It's a great solution I stumbled upon for when you want to be like "I don't know or care how this was compressed, just extract it for me"
7-Zip is the first of the three programs I install on Windows before anything else (the other two being VLC and Sumatra PDF; I wish Sumatra were available on Linux, but evince is not bad as a replacement).
7-Zip is the first thing I install alongside Firefox and Everything Search. Firefox is less of an absolute requirement with Chromium Edge but I need 7-Zip and Everything Search.
Sumatra is an incredible piece of pdf viewing software. The fact that I can just alter some css and make my own dark mode and that is not a bloated piece of annoying garbage like acrobat will keep me using it on windows machines forever.
I hope 7-Zip will support Zstandard someday, .tar.zst is getting more and more common and having to point people on Windows to install either modern7z (7z plugin for several new compression algorithms) or use zstd from the CLI is complicated.
That's exactly what I quoted in my comment. It's not necessary on Linux though, given that every environment ships a good archiving program (like Ark or File Roller) that supports zstandard.
Zstandard is getting ubiquitous everywhere: inside of RPMs, as a way to compress data onto filesystems (both Btrfs and ZFS support it) and in several other applications. It decompresses much much faster than XZ while offering a comparable level of compression (XZ is still better, but at with an unreasonably worse computational cost).
The fact .tar.zst or .tzst isn't supercommon (yet) is for the same reason .tar.xz took years to become widely adopted: lots of OSes still ship `tar`s that don't support it out of the box, like Windows (which only supports gzip actually) and macOS (which ships an old version of bsdtar and no libzst). On a reasonably new Linux, is like opening every other kind of tar.
I’ve always been confused by the popular choice of compression on tar archives. If a small portion of a gz, xz, zst, etc archive is corrupted you lose everything after it, defeating the purpose of using a stream format like Tar.
The algorithms that can recover data after the corruption like bzip2 and lzip don’t see much use these days
99.9% of the time, if a .tar.gz archive is corrupted, I don't want to recover the data - I want to redownload it from a different mirror because it's source code and it probably won't work with any corruption at all.
In the common case of receiving a compressed tar over the network, it should hopefully be protected by at least a checksum or hash, if not a cryptographic signature.
If I expect I may have to deal with some form of data corruption (such as long-term archival media), I'd rather add a layer such as PAR2 [0]. Rather than content myself with "if the tar file is corrupted, I can probably recover most of the contents", erasure coding gives me confidence that I can definitely recover all of the contents, with confidence they're not corrupted, as long as I have enough parity data.
Nobody uses Tar like that anymore. Tar is used as a more flexible replacement for ZIP nowadays, it could have easily been CPIO but `tar` had a much better command line interface.
107 comments
[ 2.9 ms ] story [ 160 ms ] threadunzip,zip,tar,gunzip,ark
And what's the difference? I alwasy though 7zip was a bit sketchy like rar archives, zips are more common on windows and on linux everywhere I see there are either gz, bz2 or xz.
xz is a much simplified version of the massively, insanely over-engineered and frankly impossible to implement 7-Zip format.
https://www.nongnu.org/atool/
[1] https://www.libarchive.org/
Edit: read the description, so it is a different port, any any apparent enhancements though?
[1]: https://www.7-zip.org/download.html
In the site that you linked:
>p7zip is the command line version of 7-Zip for Linux / Unix, made by an independent developer.
In the link for this post:
>It's first version of my port of 7-Zip to Linux.
>That port of 7-Zip is similar to p7zip, but it's not identical to p7zip.
I guess that would be why. I, too, assumed we had an actively maintained Linux port, but if the maintainer isn't doing much these days, a version closer to upstream would be great.
The 7zip author by his own admission does not use Linux, though, so I'd be curious if p7zip might actually be more performant on Linux.
Is there much to do?
Almost every release.
> or copy it to multiple flash drives or CDs
How would you use 'split' without either dumping the whole archive on disk or pluggin all drives at the same time?
The options in gnu tar are -L and -M for specifying tape length (in KB) and creating multi-volume archives.
The -L version is handy as it can prompt you to change the "tape". It has built-in tape handling as well, if you are using a real tape that can be controlled via mt.
Apparently (just checked info) it supports an arbitrary command to execute at the end of each archive. That would be handy for burning CDs, though I don't remember that feature from when I used floppies or QIC-40 to move files from one machine to another.
Around 1991-ish I would use these options to put archives onto stacks of floppy disks. The floppies didn't have a filesystem, just blocks of tar archive. In the days of 9600 bps modems, this was often the fastest way to move stuff to another machine. I had an often-reused stack of 3.5in HD floppies labeled with numbers for this purpose.
In 2015 ISO published a standard pertaining to zip archives, and one of the specifications was (from Wikipedia):
There are also multiple forum posts when you search for multipart zip archives of Linux users asking how to decompress them, suggesting that this is only WinZip behaviour and not common to the zip standard.Edit: I just found the page where you got your quote. Looks like ISO was deliberately defining a subset of ZIP.
The only way I've seen RAR used in torrents is to package everything into one big file, and since they're usually video or audio that already has lossy compression, and since I may want to prioritize or skip certain files, it's both pointless and annoying.
In what way?
And when you run an executable from it, it (I think) unzips the whole archive, not just the file, so DLLs etc. can be loaded properly. Just saves some effort and thinking when you need it and doesn't make a difference when you don't
Dolphin, PCManFM, and MC would all like a word with you.
Also, 7Zip is no harder to use than the built-in Windows zip extractor if you use the context menu.
If this is true (and I wouldn't know because I haven't had a GUI file manager on my Linux desktop since the early 2000s), it's because GUI file managers are for casuals.
There's Double Commander, which also works great on Windows and beats sibling-mentioned Dolphin and even PCManFM hands down.
There's also Ranger and nnn, if you need a CLI and don't want an orthodox file manager.
Winrar does it fine.
And very annoyingly, 7zip has had for years a race condition where when you open a file inside an archive, it extracts the file in the temporary folder and then... it deletes it before the associated application manages to load it. It is hit and miss when it works - often it does, but then for some reason i haven't figured out it just deletes the file. And related to that 7zip extracts only the file you double click on, so e.g. it doesn't extract any data files an executable might need or images or subpages an HTML file may refer to.
I have both installed and in my experience WinRAR is by far the better tool when it comes to handling archives with the main exception (and the only reason i have 7zip installed) being that 7zip supports extracting from far more archive formats - including disk images (i use it all the time to extract files from VirtualBox, PCem, etc disk images and seems to support a variety of file systems too).
I’m not dissing Igor Pavlov. He’s a very skilled developer as for compression format development. But he ought to get some assistance on the archiver software front.
yea, sourceforge went throu a lot of sketchy shit but nothing an adblocker and common sense could not defeat.
[1] https://www.libarchive.org/
https://m.youtube.com/watch?v=V_Iz4zdyRM4
No idea how this new build differs.
windows-only, though (and 3rd-party)...
The fact .tar.zst or .tzst isn't supercommon (yet) is for the same reason .tar.xz took years to become widely adopted: lots of OSes still ship `tar`s that don't support it out of the box, like Windows (which only supports gzip actually) and macOS (which ships an old version of bsdtar and no libzst). On a reasonably new Linux, is like opening every other kind of tar.
The algorithms that can recover data after the corruption like bzip2 and lzip don’t see much use these days
- if you know tar supports your directory / metadata, you don't have to lookup if zst will preserve that info
- interfile compression
I don't think people would say they use tar because it's a stream format. They use it because it packages files/directories into a file
If I expect I may have to deal with some form of data corruption (such as long-term archival media), I'd rather add a layer such as PAR2 [0]. Rather than content myself with "if the tar file is corrupted, I can probably recover most of the contents", erasure coding gives me confidence that I can definitely recover all of the contents, with confidence they're not corrupted, as long as I have enough parity data.
0: https://en.wikipedia.org/wiki/Parchive
https://github.com/mcmilk/7-Zip-zstd/releases