Talk:Comparison of file archivers

7-Zip should be 7z?

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

RK and WinRK

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

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]

WinACE and the ACE format

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

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

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

Batch conversion

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

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]

Operating systems?

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)

RAR on UNIX

	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]

Real-life comparisons

7-zip vs IZArc vs TUGZip

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"

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]

Merge Tag

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. (Bjorn Tipling 21:52, 4 July 2006 (UTC))[reply]

File Chopper

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

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

Originator of Infozip

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]