Talk:Comparison of file archivers

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software.

A complete misunderstanding of archiving[edit]

From http://en.wikipedia.org/wiki/Archive
"An archive is a collection of historical records, or the physical place they are located."
This article is about file compression and packaging. NOT archiving. Archiving DOES NOT EQUAL compression or packaging neither does compression and packaging equal archiving.
Archiving a file MAY employ compression and archiving a set of files MAY include packaging too it but does not need these, does not depend on these.
One of the key point of an archive is PRESERVATION. None of the listed softwares provide this. Files 'archived' with these softwares can be wiped out by a simple virus if the package is on the same computer. You can - and should - move the package to another device where it is safe and THIS would be archiving it. But this MOVE can be done without compressing/packaging.
Thus these are not archival but compressor/packaging softwares.
Please change the title. — Preceding unsigned comment added by 192.102.250.181 (talk) 02:08, 3 July 2012 (UTC)[reply]

By Unix naming convention, a file compromising a set or tree of files is called an archive. Just as something a mathematician calls “smooth” does not necessarily be tangible or look smooth, something a (Unix) programmer calls archive does not necessarily be the same thing a librarian calls “archive.” This nomenclature comes from the original use case for archives: To archive data on tapes. A Unix system views a tape as a large file. This file is not formatted with a file system, as this is impractical due to the difficulty in seeking on tapes (tapes with file-systems do exist but were used to a lesser extent on Unix). Instead, multiple files are packed into an archive file that can be restored into multiple files when needed. This is reflected in the naming convention of the Unix archivers ar (archiver) and tar (tape archiver, supports directories). Note that these programs do not contain file compression functionality. In accordance with the Unix philosophy and the memory limitations of the day, compression is implemented in a separate program called compress. Please don't complain here. Wikipedia is not the right place to complain about unusual, weird, or unintuitive nomenclature. --FUZxxl (talk) 16:32, 4 April 2015 (UTC)[reply]

Wanted: PAR support information[edit]

The table that identifies software support for popular archive formats is missing a column for PAR (parchive) format. Should we include it here? This also implies adding applications like SmartPAR. —Preceding unsigned comment added by Anon lynx (talk • contribs) 17:48, 14 April 2008 (UTC)[reply]

Shell integration?[edit]

This column in the "Archiver features" table has different meanings for different operating systems, and they seem to have been used inconsistently. Under UNIX-like systems, the integration is usually provided by a third program (such as File Roller), so most archivers would have "shell integration" there. But under Windows, each archiver needs to provide the integration by itself. IMO there should either be some definition of the "shell integration", or the column should be removed. --Crashie 17:38, 25 February 2007 (UTC)[reply]

More Features[edit]

There are some features which could be added such as

multi-volume and self-extracting at the same time

Ability to execute a program before/after extraction

Ability to use date/time/fileversion/size-is-greater/less/equal to decide whether to overwrite when extracting

Ability to update archives for add/delete files

Size of overhead when creating self-extracting archives —Preceding unsigned comment added by 199.84.137.3 (talk) 20:44, 18 February 2009 (UTC)[reply]

"File repairing"[edit]

My reason for arriving at this page was to find out which expander/archivers have better error-recovery repair features.

I find it immensely annoying when utilities suffer from the common software blight of failing at petty non-compliance to some absolute standard, followed by dumb insolence and a confusing, non-specific error-message. Bah. CRC error? ok. tell me it might be a corrupt archive, I can sandbox it; don't just fail stupidly. A missing part of a multi-part archive? Again, it's no reason to stop all processing, maybe I'll settle for what there is, it may contain the info I want.

The column in "features" relating to file repair is a little cursory; for example, I was just using Peazip, and although it is credited with "file repairing - yes", it will make no attempt to recover a difficult RAR file, indeed its resilience vis-à-vis other formats seems to me to be quite limited.

So, I wonder if this topic could be covered in a little more depth, with maybe an indication of which expanders are 'best' at minor repairs, or will cope with partial recoveries.Memethuzla (talk) 15:17, 24 December 2010 (UTC)[reply]

7-Zip should be 7z?[edit]

On both Reading and Writing, shouldn't it say 7z instead of 7-Zip on the table header? Because 7-Zip is the program while 7z is the format. If you don't get what I mean I'll show you in these tables (I only include one entry to save space):

	ZIP	TAR	gzip	bzip2	7z	RAR	LHA	ACE	StuffIt	StuffIt X
7-Zip	Yes	Yes	Yes	Yes	Yes	No	No	No	No	No

instead of

	ZIP	TAR	gzip	bzip2	7-Zip	RAR	LHA	ACE	StuffIt	StuffIt X
7-Zip	Yes	Yes	Yes	Yes	Yes	No	No	No	No	No

--ReCover 20:54, 29 January 2006 (UTC)[reply]

Yes. I fixed it. --Karnesky

Maximum File Size[edit]

we've been having a problem whereby the native windows 2003 archive creator craps out if the archive is greater than 2GB. perhaps there should be some discussion of this on the page. --195.50.80.2 (talk) 13:08, 9 June 2009 (UTC)[reply]

I also need information about comparison maximum size can handle of each archiver. As so far, I surprised that 7zip can handle 17 GB zip file rather than WinRAR or Windows XP built in compressed zip manager. Ndrasen (talk) 06:44, 14 July 2010 (UTC)[reply]

RK and WinRK[edit]

We should probably add RK, it currently has the highest compression of the commercial archivers, and seems to be compatible with everything. —Preceding unsigned comment added by 63.105.65.5 (talk • contribs)

It appears that it has been added by User:202.89.139.117. --Karnesky 20:21, 16 March 2006 (UTC)[reply]

WinRAR[edit]

How come there is no entry for WinRAR?

Because the contributors don't use it / don't know information about it / don't want to add it. Want it? Be bold and do it yourself. --Minghong 12:27, 23 Mar 2005 (UTC)

Just added it. --Davitf 11:07, 20 Apr 2005 (UTC)

Note, that file repairing is advertised for WinRAR, but I've tried several times, unsuccessfully, to repair RAR archives - the application just stood in a tight loop for a few days, wasting CPU cycles, until I killed it. (For the record, the archive merely had some blocks full of zeroes, with the header intact.) Should a footnote be created about it, or should it be marked as no support?

since we aren't really supposed to do original research and since the merits of a repair function are something that can be proven quickly and easilly i think we should just add a disclaimer along the lines of. "repair features are hard to test objectively, this column merely indicates that such a function is present not how well it works". Plugwash 7 July 2005 02:47 (UTC)

Not to mention that WinRAR's archive repairing works just fine - I've several times used it to recover archives several hundred megabytes in size that had been corrupted when downloading. Sounds like the anonymous contributor has either been rather unlucky, or has been expecting the impossible. Haeleth 21:27, 27 September 2005 (UTC)[reply]

Also Wikipedia is an encyclopedia would World-Book Say that? We should only talk about features as they are described by official statements from the producers. ------- this my be a bit extreme Oxinabox1 08:38, 2 February 2007 (UTC)[reply]

WinACE and the ACE format[edit]

As the RAR format did, ACE could also deserve to be inserted in this entry. Because we would then need another column for format support, I'm just putting this into the discussion. --213.7.160.98 16:01, 24 August 2005 (UTC)[reply]

Done, done and done. —deanos^{}{ Ł }{} 12:19, 27 October 2005 (UTC)[reply]

Non-compressing Archivers[edit]

Using the Wikipedia definition of file archiver, an archiver is an application that makes many files into one file, without necessarily compressing them. So Unix tools like tar, cpio, etc. should be added to the comparison. If that's done, then a Compression column should be added to the Features table. Also, readers would probably want a comparison of typical compression ratios for each archiver, as difficult as that is to state with any certainty or authority. Thoughts? -- Needs a Wiki account....

That will be another article, like "comparison of file archive format", which compares compression ratio, compression speed and decompression speed, which are hard to be done as not all archivers are available to an OS (have to compare under the same hardware). However, if everyone want to do that, it should be nice. :-) --Minghong 12:33, 23 Mar 2005 (UTC)

I'm starting to work on this. I've linked "GNU tar" to the tar archive format, which is not ideal but the best so far. Not sure when the first public release was; the earliest reference I can find to GNU tar (as opposed to some unnamed tar used to distribute GNU software) is 1989. -- Ibid.

:I've reverted it. These non-compressing tools are basically another category of software. (Seen the mess in mixing audio player and video player in comparison of media players?) Can't compare at all. --Minghong 12:30, 23 Mar 2005 (UTC)

I haven't seen the mess in the media players article, but file archivers doesn't limit archivers to compressors, and doesn't even mention compression until the fifth paragraph. In fact, it includes ar, tar, and cpio as examples. Either the two articles should consider the same scope of archiving tools, or this article should use its own and state the criteria up front. In the latter case, I'd suggest a notice to the effect of, "This article compares full-featured file archiving programs that combine multiple files and compress them using multiple formats. For simpler archiving tools, see list of file archivers." Then we'd have to get rid of Infozip and PKzip, too, as each only knows one format. Is that option worth pursuing, or should the article be left as is?

Just leave it as it is. It should be fine. --Minghong 21:09, 23 Mar 2005 (UTC)

No, this article doesn't seperate the archivers from the compressors. Those are two completely different things! This is like the crap you read in pc magazines, not an encyclopedia.

Thing is in MOST cases a format combines archiving and compression and this is the model users have come to expect. The main exceptions are tar on the archiving side and gzip and bzip2 on the compression side. Plugwash 08:36, 21 Apr 2005 (UTC)

Tar[edit]

What does "seperate" in "file repairing" mean? --minghong 05:21, 1 Apr 2005 (UTC)

I also wonder what that column means. Most formats don't even have any support for file repairing, or require it to be enabled proactively (such as RAR), so why is it “Yes” for so many archivers? Or is “repairing” simply ignoring errors in the archive? --Crashie 17:09, 25 February 2007 (UTC)[reply]

Batch conversion[edit]

What is meant by "batch conversion"? I think an explanation of the most obscure features would be helpful. --Davitf 11:07, 20 Apr 2005 (UTC)

Never heard of it [1]? Basically it means that the software can convert a batch of archiver files from one format to another format. --minghong 11:53, 20 Apr 2005 (UTC)

tar/gzip/bzip2[edit]

tar is nearlly always used and shipped together with gzip and/or bzip2. how is supporting compression by working closely with an external executable any different from doing it by calling say a dll? imo its very misleading to put a categorical no in support for compression with tar without explaining this. Plugwash 21:38, 18 Jun 2005 (UTC)

I have corrected this; GNU tar does support both gzip and bzip2 compressions and you would need to delete files in /bin yourself to disable this support. And, yes, GNU tar has full gzip and bzip2 support when installed with cygwin and mingw32's msys on Windows. Samboy 03:07, 27 December 2005 (UTC)[reply]

The table says gzip can _write_ TAR files (and bzip2 files). Seems a bit confusing if not misleading -- the version of gzip I have installed with cygwin cannot directly generate bzip2 or tar files. Perhaps adding some footnotes would help.—Preceding unsigned comment added by 209.76.218.2 (talk • contribs)

bzip2 isn't even listed in the tables. Given that they can each only read and write to their own formats (and that this is rather obvious), I'd propose removing them from those particular tables. --Karnesky 21:22, 23 May 2007 (UTC)[reply]

Operating systems?[edit]

Why are the operating systems on this page limited to Windows, MacX, Linux, BSD, and UNIX? I also use ZIP compression on IBM, both mainframe and midrange?

Because these are the more widely used ones. --minghong 9 July 2005 07:26 (UTC)

I think it'd be worth adding an 'Other' column, where further OSes could be included as appropriate. -- Trevj (talk) 15:27, 30 April 2012 (UTC)[reply]

RAR on UNIX[edit]

	Windows	Mac OS X	Linux	BSD	Unix
WinRAR	Yes	Yes³	Yes³	Yes³	No

Mac OS X and BSD are Unices so RAR can run on Unix.

I guess what is meant is with Unix is other Unixes (Solaris, Irix, etc. p.p.)--Hhielscher 11:20, 16 October 2005 (UTC)[reply]

Fixed. It's called "Other Unix" now. 84.46.14.221 (talk) 12:21, 4 November 2008 (UTC)[reply]

If it does not run on Solaris, it does not run on UNIX. Note that Solaris is a certified UNIX and that software that runs on one certified UNIX will run on any certified UNIX. --Schily (talk) 23:36, 9 December 2011 (UTC)[reply]

Real-life comparisons[edit]

7-zip vs IZArc vs TUGZip[edit]

What's the "real" difference between 7-Zip, IZArc and TUGZip ( ... besides the differenciate development streams)? --(non en Wikiped account reg'd)—Preceding unsigned comment added by 84.72.93.77 (talk • contribs)

7-Zip is LGPL and very complete feature wise. IZArc and TugZip are very complete too but are proprietary. Personally, I use 7-Zip, because if there's a open tool and a closed tool that both do the same jobs, I would use the open tool. — Ambush Commander^(Talk) 18:41, August 7, 2005 (UTC)

Compression ratio, speed, and "efficiency"[edit]

What about adding bzip2, gzip, as mentioned earlier and making a comparison more like real-life use. I mean compression ratio of various data, compression speed. One could then decide what archiver is the best for him.—Preceding unsigned comment added by 83.28.7.81 (talk • contribs)

That should be compared, but should be compared in something like "comparison of file archive formats" --210.17.225.138 04:29, 12 August 2005 (UTC)[reply]

The problem is that, while such information is useful, it would be original research. Maybe we can just report the research places like this and this have done. Samboy 03:18, 27 December 2005 (UTC)[reply]

The efficiency of the archivers should be compared not only the features.—Preceding unsigned comment added by 83.25.247.191 (talk • contribs)

Efficiency in what?--Someoneinmyheadbutit'snotme 21:25, 15 March 2006 (UTC)[reply]

Presumably this refers (again) to the compression ratio. Even if it doesn't, nearly anything else that could have been meant would need the same kind of OR or the use of biased/controversial/limited sources as these things.--Karnesky 20:30, 16 March 2006 (UTC)[reply]

Software version used for measuring performance[edit]

With some archivers (like RAR) the version of the software that is used greatly influences the performance values, both in speed and acquired compression ratio (not to mention platforms it was run on, both hardware and OS-wise, as these results may have been acquired on different platforms, there is no way to tell). --213.84.89.224 13:26, 4 February 2007 (UTC)[reply]

Merge Tag[edit]

Since I see no section about the merge tag, and since I believe that this merger is pointless and unnecessary, I am calling for the removal of the merge tag. Anybody second me? HoCkEy_PUCK, 23:33, 28 February 2006 (UTC)[reply]

I agree with you. The request of a merge seems to be in every other comparison/list article, e.g. Talk:Comparison_of_e-mail_clients#Merge_from_List_of_e-mail_clients.--Hhielscher 03:50, 1 March 2006 (UTC)[reply]

I placed the merge tag there & haven't yet had the time to do the merge myself. I think it would be productive to merge the list to here--the list attracts more link spam & is ultimately less useful than the comparison. Ideally, the comparison would be a superset of the list & would deprecate it. --Karnesky 17:20, 16 March 2006 (UTC)[reply]

I agree. Remove the tag. the article is long enough and informative enough for a standalone version. Vivek 01:23, 20 May 2006 (UTC)[reply]

I reluctantly acquiesce. I continue to believe that a merge would greatly benefit both this page and the list (and the list ISN'T a good standalone article, which is why I'd like it merged to here). However, I haven't had time to perform the merge myself & don't see a lot of effort in this area. Please consider removing only the mergefrom tag & not the mergeto tag. --Karnesky 03:17, 20 May 2006 (UTC)[reply]

Since everyone is in agreement I will remove the tag. (Narkstraws 21:52, 4 July 2006 (UTC))[reply]

A list and a comparizon are two different things - one may need the one and not the other - a bad article should not be merged, deleted , etc but amended - are you really willing to compare all the progs listed ? In short untag it :) The Ubik 03:55, 30 November 2006 (UTC)[reply]

Alternative Proposal[edit]

How about merging this article into file archiver (as a section) as that article is quite short and it seems strange that it doesn't any examples of archivers. One could then put a template:main link to Comparison of file archivers in that section. Just an idea.

Joe Llywelyn Griffith Blakesley _talk _contrib 12:08, 15 February 2007 (UTC)[reply]

File Chopper[edit]

I was hoping this article would help me pick an application to help me chop a file. IE break it into pieces small enough I could email them. Mathiastck 17:43, 8 August 2006 (UTC)[reply]

I don't think archiving is intimately related to splitting. If we start getting more articles than Split (Unix), perhaps a new comparison article would be appropriate. --Karnesky 18:15, 8 August 2006 (UTC)[reply]

AlZip[edit]

AlZip (Alzip?) deserves inclusion here. It's capabilities are up to the best of them, including being able to read most of the formats on the chart. It's apparently a Korean program. 2006-08-18 15:33

I agree on this. ALZip supports most of the file formats in the tables, is freeware, and has system integration. It run only on Windows. Mariano(t/c) 11:43, 17 October 2006 (UTC)[reply]

Originator of Infozip[edit]

Should Phil Katz be listed as the originator of Infozip? Granted that he invented the file format with Pkzip, he didn't originate the source code of Infozip, did he? --Richardthiebaud 19:55, 29 August 2006 (UTC)[reply]

Good catch. According to the Info-ZIP article, "The first version of what would become Info-ZIP was published by Samuel Smith in March 1989, complete with the source code in both Pascal and C forms. In September he released 2.0, including support for the new "implode" method that had been added to PKZIP 1.01. A port to Unix was released by Carl Mascott and John Cowan in December." While the man page says "Copyright (C) 1997-2005 Info-ZIP; Copyright (C) 1990-1997 Mark Adler, Richard B. Wales, Jean-loup Gailly, Onno van der Linden, Kai Uwe Rommel, Igor Mandrichenko, John Bush and Paul Kienitz." Anyone know the reason for the man page not to have copyright info for 1989? Should Samuel Smith be cited as the creator? --Karnesky 20:17, 29 August 2006 (UTC)[reply]

The license tells all --Karnesky 20:19, 29 August 2006 (UTC)[reply]

Archive format support and program version[edit]

The table would be more helpful if it would include the number of the version that could read/write the format first. Like in Comparison of layout engines (XHTML).--Hhielscher 09:03, 17 October 2006 (UTC)[reply]

There's one archiver missing in the list. I miss the UC and UC2 tool.

Peazip: A plethora of supported formats

Not that I'm promoting it, but for information, Peazip's full spec page claims it supports all these:

Full support: 7z, FreeArc's arc/wrc, sfx (7z and arc), 
             bz2, gz, paq/lpaq/zpaq, pea, quad/balz, 
             split, tar, upx, zip

Read (browse, extract, test) 126 file extensions: 
             7z, bz, bz2, bzip2, 
             tbz2, tbz, gz, gzip, tgz, tpz, tar, 
             zip, z01, smzip, arj, cab, chm, chi, chq, chw, 
             hxs, hxi, hxr, hxq, hxw, lit, cpio, deb, 
             lzh, lha, rar, r01, 00, rpm, z, taz, tz, 
             iso, jar, ear, war, lha, pet, pup, pak, pk3, pk4, 
             slp, [Content], xpi, wim, u3p, lzma86, lzma, udf, xar, 
             dmg, hfs, part1, split, swm, tpz, kmz, xz, txz, vhd, 
             mslz, apm, mbr, fat, ntfs, exe, dll, sys, msi, msp, 
             ods, ots, odm, oth, oxt, odb, odf, odg, otg, odp, otp, odt, ott, 
             gnm, doc, dot, xls, xlt, ppt, pps, pot, docx, dotx, 
             xlsx, xltx, swf, flv, quad, balz, 
             zpaq, paq8f, paq8jd, paq8l, paq8o, lpaq1, lpaq5, lpaq8, 
             ace (with a plug-in), arc, wrc, 001, pea, cbz, cbr, cba, cb7, cbt, (and more...)

However, Peazip is severely limited by its refusal to deal with UTF-8 filenames

Repair: FreeArc's arc/wrc

Which isn't much in the way of repair.

Also, I'm a little curious about the sequence of archive formats not being alphabetical. Is that a matter of progression, popularity, or a subtle form of pre-compression normalisation?

Memethuzla (talk) 13:53, 24 December 2010 (UTC)[reply]

compression time vs compression rate[edit]

This page needs a table on the actual efficiency-related comparisons (what I expected when I came to this page). I'll try to find some, but those would be much more useful than comparison of anything else. Fresheneesz 03:15, 1 December 2006 (UTC)[reply]

StuffIt Expander is not an archiver[edit]

StuffIt Expander does not archive anything. It cannot create or modify any kind of archive. It just expands / extracts archives created by other things. —The preceding unsigned comment was added by Spoon! (talk • contribs) 01:37, 13 January 2007 (UTC).[reply]

I agree. Since the main topic is "file archivers", it means softwares that create archives. The StuffIt Expander is indeed just an archive extractor. I also found that Zipeg is only an archive extractor. Therefore, I am suggesting for a removal of both StuffIt Expander and Zipeg from this article. --Jaelanicu 14:27, 27 October 2007 (UTC)[reply]

Does anyone insist on keeping these entries? If so, please say so, and we can discuss it. If not, I'm going to remove entries about extractor-only software. 84.46.6.142 (talk) 10:22, 15 November 2008 (UTC)[reply]

Since noone piped up so far, I have removed both Zipeg and Stuffit Expander because they are both only extractors. What's more, even technically they are not very interesting: Zipeg uses the 7-Zip backend and Stuffit Expander probably uses the Stuffit backend. —Preceding unsigned comment added by 84.46.14.202 (talk) 13:44, 20 November 2008 (UTC)[reply]

Unusual Support Expansion[edit]

A list of programs would be nice. Plus a small discussion on the .exe format, as well as other formats. --ANONYMOUS COWARD0xC0DE 04:02, 27 January 2007 (UTC)[reply]

Supported OS[edit]

I think we can't say that e.g. winrar "runs" under Linux. It runs only on 32bit Intel/AMD/... CPUs, which is only one out of 20(!) architectures which are supported by Linux (unless you think that running in 32bit Mode under x86_64 means that architecture is supported). Moreover most Distributions don't include it, because of it's unfree/closed-source. It's the same with some other compression and BSD OSes and other Unixes. 62.47.128.92 18:15, 8 April 2007 (UTC)[reply]

Fixed. Please notice that as of my change, there is an explicit Linux x86-64 version. 84.46.14.221 (talk) 12:21, 4 November 2008 (UTC)[reply]

UHA[edit]

UHA Archive has high compression algorithm which is mostly used to compress large files like games and software. It uses the most used algorithm like LZMA, LZMA2,PPA etc (Inbuilt Media Archiver). Its Initial release was in CMD version and later GUI versions were released.

Winrar and ISO images.[edit]

As of winrar 3.5, Winrar has supported .iso cd images. And yet it is listed as not supporting it on the table. Unless you mean by creating the archives, I think this should be corrected. --70.114.39.158 20:37, 28 June 2007 (UTC)[reply]

JZip article nominated for deletion[edit]

Please discuss on its AfD page. --AVRS 12:49, 6 September 2007 (UTC)[reply]

UNICODE FILENAMES?[edit]

In our age a good file archiver should support Unicode file names. (Worldwide the majority of the people uses Unicode file names / path names nowadays.) Good old ZIP is quite obsolete in this respect, while 7-zip and WinRAR can handle it. I think it should be included into the comparison. —Preceding unsigned comment added by GaborV (talk • contribs) 13:41, 14 September 2007 (UTC)[reply]

---NOTE: zip format supports Unicode for some time now (writing this in 2009). Someone should correct the page. (Hope this edit is in the right location.) —Preceding unsigned comment added by 70.89.232.180 (talk) 06:50, 4 January 2009 (UTC)[reply]

Agreed.

Also good to mention would be file owner/group and permissions, support which may differ between platforms. --AVRS 11:27, 15 September 2007 (UTC)[reply]

I've added a new column in the archiver features section. It was added as an anonymous user. I forgot that I already have a wiki account (I'm very new at this). Last update added several achivers. Then I add PKZIP after I logged into wikipedia. I hope the new column will be helpful for everybody.

I'm currently testing several other archivers. Hope I could add them to wiki also. --Jaelanicu 18:23, 9 October 2007 (UTC)[reply]

Please consider also adding info like "supported folder nesting depth", "maximum filename length", "maximum path length" ... Thanks, --Xerces8 (talk) 14:30, 23 December 2007 (UTC)[reply]

UltimateZip, FreeZip, ICEOWS, QuickZip[edit]

Is there a reason why Ultimate Zip and FreeZip (reviews on that page and here) and ICEOWS and QuickZip are missing? They're free and very good and have different advantages. --Espoo 06:25, 19 September 2007 (UTC)[reply]

Basic Zip?[edit]

Where is the website for Basic Zip? I've Googled it but couldn't find it? Thank you in advance. --Jaelanicu 20:21, 9 October 2007 (UTC)[reply]

Edit: I also couldn't find the Beezer archiver. --Jaelanicu 20:44, 9 October 2007 (UTC)[reply]

Tar Should Point to GNU Tar and/or Have It's Info Corrected[edit]

In the table of archivers, the tar(1) entry points to the article on the file format, but the rest of the information in the table refers to GNU tar only. In particular, tar wasn't invented by the GNU project. Either the info should be changed to give proper credit to whatever old school UNIX hacker really invented tar, or the link should go to GNU tar. —Preceding unsigned comment added by 69.87.200.131 (talk) 11:39, 15 January 2008 (UTC)[reply]

Done. Also there are are public domain, BSD-style, and proprietary versions of tar as well as GPL versions, so changed license to 'various.' Kaelfischer (talk) 07:26, 7 August 2008 (UTC)[reply]

inclusion of Squeeze?[edit]

There is a file archiver called Squeeze (not to be confused with Squeez) for Xfce... I was wondering if someone could get it's stats into this article? I would, but as of yet, my knowledge about it is too limited to be very useful. However, I do know, factually, that this is not the same archiver as Squeez. —Preceding unsigned comment added by 209.173.174.235 (talk) 18:22, 14 May 2008 (UTC)[reply]

LHA?[edit]

I know it's not supposed to be an exhaustive list, but what's happened to the middle section of each of those tables, between K and P? I thought someone had vandalised them all at first, but it must have been a very autistic vandal. LHA/LZH used to be pretty widespread inasmuch as I remember, and you've gone to the trouble of including it in the final table (where it puts in a sadly poor show, but only by a small percentage behind ZIP), why not the others?

meh :-/ 77.102.101.220 (talk) 23:49, 21 May 2008 (UTC)[reply]

Stuffit for Linux & Solaris[edit]

I think it deserves mention that Stuffit for Linux and Solaris is a (very) old version. Cute as the Stuffit makers are, they won't let you know which version it is. Personally, I have no interest whatsoever in downloading either version, but several sources of debatable credibility seem to indicate that at least the Linux version is 5.2.0, and I guess the Solaris version as well. These sources I'm referring to are: http://linuxmafia.com/faq/Apps/stuffit-archives.html (also claiming segfaults on modern systems) http://rpm.pbone.net/index.php3/stat/4/idpl/4052527/com/stuffit-5.2.0.611-1plf.i586.rpm.html Also, since the official page for Stuffit for Linux and Solaris refers to "Sun Solaris 2.7 or later" and "Red Hat Linux 6.x" I'd hazard a guess that the page wasn't updates for several years! ;-) Unfortunately, I couldn't find out when the 5.2.0 version of Stuffit itself was released. If we reach a consensus here about Linux/Solaris support, then it should also affect the Wikipedia Stuffit entry. Does anyone have credible sources, or has anyone tried the Stuffit Linux and/or Solaris versions themselves and can make an informed decision about this issue? 84.46.6.46 (talk) 00:22, 4 November 2008 (UTC)[reply]

 The shareware Linux binary can be downloaded at this location without having to provide an email address:
 http://www.pctipp.ch/index.cfm?pid=1411&pk=32080
 When called from the command line, the program identifies its version as:
 stuff 5.2.0.611 2001/06/28 15:24 - archive creator
 unstuff 5.2.0.611 2001/06/28 15:24 - archive expander

97.119.32.38 (talk) 16:26, 6 January 2010 (UTC)[reply]

WinZip Vs WinRar[edit]

I believe winzip is not as good as win winrar when compared in memory space occupitation and hard disk also. Thought file association is better but use-less. —Preceding unsigned comment added by 117.192.133.92 (talk) 18:36, 30 March 2009 (UTC)[reply]

FreeZIP?[edit]

Would someone be so kind as to add FreeZIP? -- the URL is http://members.ozemail.com.au/~nulifetv/freezip/ I myself like it for not having a GUI; it just adds options to the right click menu. BTW, some people mistakenly think it only unzips, but it will zip as well -- it just limits itself to zipping entire directories, not individual files, and you can always make a directory and put one file in it. Very minimal, but it gets the job done.

72.251.91.211 (talk) 13:11, 14 May 2009 (UTC)[reply]

batch create - separate archives[edit]

The "batch conversion" column needs more work. What exactly is it supposed to mean?

It is a common task to want to create separate zip archives from each subfolder within a folder. But hardly any of these archivers seem able to do this simple task from the GUI, except in a very tedious manual way! Which ones have this ability, if any? Please add this info to the tables. -68.236.103.195 (talk) 20:29, 6 June 2009 (UTC)[reply]

NanoZip[edit]

NanoZip is an upcoming file archiver. It consists of several original compressors, put into a single file archiver program. The project goal is the highest possible compression efficiency.

-68.236.103.195 (talk) 20:29, 6 June 2009 (UTC)[reply]

FreeArc[edit]

FreeArc is a modern general-purpose archiver. FreeArc is fast but efficient compression and rich set of features.

Advantages:

- Free, open-source, with console and GUI versions for both Windows and Linux. - Includes LZMA, PPMD, TrueAudio and generic Multimedia compression algorithms with automatic switching by file type. - Filters that further improve compression: REP (finds repetitions at the distances up to 1gb), DICT (dictionary replacements for texts), DELTA (improves compression of tables in binary data), BCJ (executables preproccesor) and LZP (removes repetitions in texts). - Special compression algorithms are used in fast compression modes (GRZIP for texts and Tornado for binary data). - Overall, 11 compression algorithms and filters are included (compared to 3 in 7-zip and 7 in RAR). - Smart file sorting that groups similar files together and fully customizable sorting order further improve compression. - Typically, 1.5-3 times faster than best programs in each compression class while retaining the same compression ratio.

Disadvantages:

Compared to RAR and 7-zip, FreeArc at this moment lacks the following: multi-volume archives, 64-bit version, storing of file attributes/extended timestamps/NTFS streams in the archive, bcj2, data segmentation. These are planned to be fixed in subsequent versions.

-68.236.103.195 (talk) 20:29, 6 June 2009 (UTC)[reply]

Universal Extractor[edit]

Would Universal Extractor be a worthy inclusion here? It's for Windows and supports most of the formats and has integration. —Preceding unsigned comment added by 80.202.244.134 (talk) 13:51, 26 August 2009 (UTC)[reply]

Deflate64/Zip64[edit]

Not all archivers are able to open files larger than 2, or in some cases 4GB. For example, the default Archive Manager in Ubuntu does not open files larger than 4GB, but p7zip does. A comparison among all archivers would be a good addition to this article as these large zip files become more common, in this case a 9GB archive distributed as a BitTorrent download for Aion. 67.160.39.126 (talk) 17:37, 9 September 2009 (UTC)[reply]

Deflate64 is not the same as Zip64, and has nothing to do with 2/4GB limits. --130.232.85.15 (talk) 14:22, 17 September 2009 (UTC)[reply]

New Features Column[edit]

How about adding whether or not the program comes in a 64-bit variant, since if it's only 32-bit, then the shell features won't work in 64-bit Windows. —Preceding unsigned comment added by Chris122990 (talk • contribs) 23:03, 2 October 2009 (UTC)[reply]

FreeArc and PowerArchiver doesn't have 64-bit versions but go with 64-bit Explorer extensions. OTOH 64-bit support is still interesting since such archivers should be faster and able to process more files and produce smaller archives. Multithreading support (whether 1, 2 or >2 cores may be used) is also interesting Bulat Ziganshin (talk) 19:45, 16 June 2010 (UTC)[reply]

Alphabetical order[edit]

Why is the list of archivers not in alphabetical order? (Look at where "tar" is in the list.) —Preceding unsigned comment added by ATBS (talk • contribs) 04:51, 18 November 2009 (UTC)[reply]

section "Archiver features" should include CLI availability[edit]

I would suggest that "CLI availability" (command line interface) should be added to the table in section "Archiver features". (I'm sorry, I don't know how to edit wiki tables). --boarders paradise (talk) 16:11, 16 April 2010 (UTC)[reply]

Actually, it should be separate for every OS, since you may have Linux CLI version but no Win32 one. Now DOS column used for this purpose. I think it should be fixed: winzip, freearc, nanozip and other archivers have no DOS versions, only Win32 CLI ones Bulat Ziganshin (talk) 14:37, 17 June 2010 (UTC)[reply]

section "Archiver features" FreeArc[edit]

In the line of FreeArc of section "Archiver features", you see "Yes[2]". But the [2] note refers to GNU Tar which doesn't match. —Preceding unsigned comment added by 79.141.202.219 (talk) 14:35, 8 May 2011 (UTC)[reply]

Why WinRAR and WinZIP are marked as "stopped development"?[edit]

I don't understand "Note: Archivers in purple are no longer in development.". WinRAR and WinZIP are marked by purple. Why??? Bulat Ziganshin (talk) 14:45, 17 June 2010 (UTC)[reply]

They are not in purple. Look at the row header (left column). Some of them have a gray background, and some of them have a gray-purple background. That is what they are talking about. You may be confused by the magenta-ish (not purple) color in the cost column which means "not free". That is unrelated. --Spoon! (talk) 18:49, 17 June 2010 (UTC)[reply]

Not sure if the color codes have been changed or someone's monitor or eyes are a bit color deficient. You should see number 74, not 21 in the picture.

In any case, #adf or #AADDFF is close to #B0E2FF, the code for LightSkyBlue1; Purple would be G < R < B like #A020F0.

Now I forgot what I came here for in the first place.. DS Belgium (talk) 02:38, 23 October 2011 (UTC)[reply]

Historical note: this sounds like a confusion about the color of a followed link being confused with the background color of the table cell. Ryper (talk) 14:25, 9 September 2021 (UTC)[reply]

New Features Column (File Descriptions)[edit]

Please add a column, to determine that the archive format supports "File Descriptions" or not. File descriptions (outside of file) is very important in many languages (such as asian languages, arabic and persian). Because in these languages, english file names are common.

Modern Format Only Option[edit]

Many people coming to the page are only interested in comparing current formats to decide which to use. However, because all of the comparison tables are multiple screens long and compare every format that has existed, they find the page to be mostly useless. We need a way to show only current information for those who want it, in order to increase utility. A method for allowing the viewer to sort information and suppress what they don't need would also be good.

This is a general comment applicable to all comparison articles. —Preceding unsigned comment added by 136.142.206.28 (talk) 22:39, 15 October 2010 (UTC)[reply]

Electronic media compression[edit]

Stuffit seems to be labelled as the only tool capable of "electronic media compression" This kinda is stupid from the point of view of [data entropy]] -- a good lossy compressor will do a final pass with a losless compressor as needed. The footnote describes this as the compression of JPEG files, and that "An average improvement of >5% is required to qualify.".

Several problems

Whose/which JPEGs?
Who set the 5%?
Why JPEG? This is not the only lossy compression program.
JPEG is not "electronic media", it is a single type of electronic media.

This seems (1) pointless and (2) overly touted. I don't know who put that there, but to have it there at all is silly, and to place it in the second column (particularly when this is unreferenced, and all the others are set to "no", seems POV-vy). 129.67.86.189 (talk) 19:51, 3 December 2010 (UTC)[reply]

jZip?[edit]

Any Room for jZip? ECat200 (talk) 10:19, 8 December 2010 (UTC)[reply]

WinZip and Rar[edit]

Can WinZip write Rar files, as stated in the table? I really don't think so. --Gspinoza (talk) 14:03, 21 February 2011 (UTC)[reply]

Recent attempt to confuse people with development state[edit]

Note that tar (the most important archiver) is shown in blue and thus blue cannot be the color for software that is no longer under development. --Schily (talk) 23:33, 9 December 2011 (UTC)[reply]

Wait just a minute... I checked the page. tar (assuming you mean GNU tar) is not blue. I'm a bit confused. --Wrldwzrd89^talk 01:43, 10 December 2011 (UTC)[reply]

I dont' have GNU tar in mind.... but even GNU tar gets some development. The oldest OSS tar implementation and the most feature rich one is star, which of course is under constant development since 1982. But this is not the topic. Tar (and many other programs that are still under development) has a big blue colored field where others (no longer under developoment) have purple. I checked several times before but now I see the first time that the first column is also partially colored. So at leat text needs to become less missleading... --Schily (talk) 11:35, 10 December 2011 (UTC)[reply]

I completely agree! It is misleading in its current form. My suggestion is to toss the color for indicating inactive archivers and use italics, instead. That would clear up any confusion. --Wrldwzrd89^talk 12:01, 10 December 2011 (UTC)[reply]

Using a new color that otherwise is not used in the table would also help. --Schily (talk) 17:38, 10 December 2011 (UTC)[reply]

The simplest way to resolve this ambiguity is to edit the row header 2 template, which is used to display the color for inactive archivers. I have done exactly that, so the note actually makes sense. --Wrldwzrd89^talk 19:05, 10 December 2011 (UTC)[reply]

Or to mention that inactive refers to blue color in the first column, but now it is really very obvious ;-) --Schily (talk) 19:53, 10 December 2011 (UTC)[reply]

Missing standard archive types[edit]

Archive types like cpio and pax are not listed but a lot of proprietary niche formats. Tar compatibility is claimed for many programs, but it is a well known fact that most of these programs tend to fail when feed by a tar archive that make use of more than some rudimentary features. Someone who knows more programs from the list should fix that. --Schily (talk) 11:19, 20 December 2011 (UTC)[reply]

7-zip can read/write xz format?[edit]

I cannot believe this, as xz is younger than 7-zip and xz has been specially designed to act as a compress(1) compatible UNIX filter. --Schily (talk) 19:39, 22 December 2011 (UTC)[reply]

Yes, 7-zip can read xz, xz compression algorithm is the default compression algorithm of 7-zip and 7-zip is being developed too plaisthos 14:00, 26 December 2011 (UTC) — Preceding unsigned comment added by Plaisthos (talk • contribs)

So you have no evidence for the claim that 7-zip can read/write the xz format? Note that xz uses a different header and that it is unlikely that 7-zip knows about this. --Schily (talk) 16:49, 26 December 2011 (UTC)[reply]

As I said 7zip can read xz. I just doulbe checked it. It can also create xz files. plaisthos (talk) 19:55, 26 December 2011 (UTC)[reply]

Dear Schily. Before claiming random things, have at least a look at the relevant sites. Such as the 7-zip.org home page. It clearly states that it can read/write XZ format. --Chire (talk) 16:20, 4 January 2012 (UTC)[reply]

bzip2/gzip/xz as compression stream[edit]

I have editied the libarchive row to indicate that libarchive treats these formats only as compression stream. I.e. It cannot read a file create with bzip2 file. I think this should be check for all other archivers (espescially the tar command) or a general notice regarding the use of bzip2/gzip/... should be added. For example 7zip also supports reading the single compressed files. I am unsure how to handle this -- plaisthos — Preceding unsigned comment added by Plaisthos (talk • contribs) 14:11, 26 December 2011 (UTC)[reply]

RAR read compatibility of 7zip (and others)[edit]

As far as I know there is no free software implementaton capable of the RAR 3.0 format (at least WinRAR/unrar-free, 7zip/p7zip or Ark are not) - therefore on "clean" Linux distributions you won't be able to read any archive in the RAR 3.0 format. Maybe a footnote for the according columns in the "Archive format support" table could be added? --Tddt (talk) 15:03, 10 May 2012 (UTC)[reply]

Limitations[edit]

I think a section or extra columns on the limits of each archiver would be useful, e.g. maximum archive size, maximum number of compressed files, maximum size of uncompressed files etc.

e.g. zip has something like a 4GB limit (Or was it 2??) on uncompressed size of a file, compressed size of a file and total size of the archive, and a limit of 65535 files in the zipfile. There is a ZIP64 to get around this but it is not compatible and a bit pointless since we have more advanced compressors like RAR and 7-zip.

7-zip is an interesting one as it claims stupidly high limits, but I know that it is very limited on 32-bit systems for archiving purposes as it uses a very inefficient cataloguing (or whatever) format and can't handle more than ~10^6 files before it runs out of memory (This is before it even starts compressing!). IIRC Igor estimates 7-zip requires 1kB of RAM for each file, depending on pathlength.

WinRAR's limits are documented in its help file - 8,589,934,591GB maximum archive size and uncompressed file size, and needs ~128bytes per file (Again, depending on pathlength)

(As I write this I'm trying to compress 982,798 files in 343,490 folders totalling ~455GB on 32-bit Server 2003 and 7-zip just crapped out with its "Can't allocate memory" whereas WinRAR is happily chugging along) 77.101.174.194 (talk) 10:47, 19 July 2012 (UTC)[reply]

Bit-perfect/pixel-perfect file compression[edit]

Could someone please add info about this, as many people (most?) aren't even aware of it and it's implications on file integrity or it's perception? Here's some info from Stuffit site (bottom of page): http://www.stuffit.com/products/stuffit-file-format.html 89.153.150.71 (talk) 15:23, 21 September 2012 (UTC)[reply]

Missing app[edit]

A major omission (in my opinion) is Keka. I don't really understand how to edit tables, versus just articles which are easy to edit, so I'm not trying to add it in myself. But it's a free Mac OS X archiver/extractor. Website is http://www.kekaosx.com/en/ and it handles all the archive formats I'VE ever heard of. Nice interface, too. (Actually I came to this article in the first place to see if I needed to keep any of my other apps for archiving/extracting, besides Keka and The Unarchiver, which are the only ones I routinely use. So I thought I'd point out this app for inclusion in the list.) — Preceding unsigned comment added by 76.168.158.232 (talk) 20:31, 12 October 2012 (UTC)[reply]

I agree with the above. Keka is the go to archiver app for all the Mac power users I know. Flendon (talk) 19:38, 13 December 2013 (UTC)[reply]

I would remove PKZIP and Iarchiver. Both does not exist anymore?--Funfun2142 (talk) 19:19, 15 March 2015 (UTC)[reply]

PKZIP is of historic relevance; it's the program that implemented the ZIP file format first. It hasn't been updated in ages if I recall correctly but it's still out in the wild. --FUZxxl (talk) 15:04, 16 March 2015 (UTC)[reply]

BulkZip[edit]

I've just read this article for first time in a while and noticed the Benchmarks section seems to have been added since I last looked. I'd expect from the title for it to talk about benchmarks for multiple applications but instead it reads like a barely disguised advertisement for BulkZip, with the phrase "deemed legit by multiple sources" being particularly grating firstly for the very unencyclopedic tone but also for the fact that both sources cited go straight to the BulkZip website. I don't see how anything currently in that section is considered suitable material for this article. In my opinion the entire Benchmarks section should be removed, with any relevant data being moved to the main BulkZip article (which has its own issues but those are for another time and place). Rhapsody Scarlet (talk) 16:02, 30 August 2015 (UTC)[reply]

WinTar[edit]

Can WinTar be mentioned; it's appearantly one of the only windows utilities to make cpio archives (note: not just uncompress it, compressing it too). http://ccm.net/#ID=3199&module=download http://cpio-devalone.blogspot.com/ http://ccm.net/download/start/download-3199-wintar The other alternative is GnuWin32, but that's not a tool with a gui. KVDP (talk) 12:24, 22 December 2015 (UTC)[reply]

Note #s in tables don't match notes list.[edit]

Some or many note #s in several (or all?) tables don't match the notes list for those tables.24.123.84.22 (talk) 17:50, 18 April 2016 (UTC)[reply]

External links modified[edit]

Hello fellow Wikipedians,

I have just modified 6 external links on Comparison of file archivers. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 17:01, 11 August 2017 (UTC)[reply]