Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: henry@utzoo.uucp (Henry Spencer)
Newsgroups: comp.std.unix
Subject: Re: tar or cpio?
Message-ID: <8176@ut-sally.UUCP>
Date: Wed, 27-May-87 19:10:23 EDT
Article-I.D.: ut-sally.8176
Posted: Wed May 27 19:10:23 1987
Date-Received: Tue, 2-Jun-87 00:46:35 EDT
References: <8001@ut-sally.UUCP>, <8126@ut-sally.UUCP>
Sender: std-unix@ut-sally.UUCP
Reply-To: henry@utzoo.uucp
Lines: 44
Approved: jsq@sally.utexas.edu (Moderator, John Quarterman)

From: henry@utzoo.uucp (Henry Spencer)

Andy's comments about the facilities offered by tar and cpio are worthy
of note, but irrelevant to the P1003.1 issues.  This was actually raised
at the original /usr/group standards meeting when the question of a
standard intercharge format came up:  the facilities offered by the
current programs are quite irrelevant to the choice of format, since
the format does not dictate the user interface.  It is not especially
difficult to write "cpar" or "tpio", to get one user interface with the
other format.

I thought the choice of tar by /usr/group was a huge win, and still think
so; the extensions added in the Trial Use Standard strengthen this view.

The cpio binary format is a travesty:  unportable, non-extensible (for
example, it is sure that inode numbers are only 16 bits, often not true
today), and generally a mess.  Cpio ASCII format is better, but it still
shares some of these problems, since its field widths are sized to fit
old systems (for example, it can't deal with 32-bit inode numbers either).

Furthermore, I would note that at least the cpio binary format, possibly
the ASCII one as well, has existed in two different versions.  People who
claim that cpio is older than tar are half-lying:  the current version of
cpio is not.  I submit that the mere existence of multiple incompatible
versions of the cpio format is a major black mark against it.  Tar format
is virtually universal, with only minor (compatible!) extensions having
been made here and there.

Andy makes a good point about extensibility.  The tar format extends
gracefully because it has extra room in its header (which the existing
programs helpfully zero rather than filling with random trash) and in its
file-type code space.  (Note that the Trial Use Standard explicitly
reserves certain type codes for local extensions, and others for future
standards.  Note also that the Trial Use Standard's own extensions are
upward-compatible with the existing format and existing programs.)

Chapter 10 of the Trial Use Standard is a valuable part of the standard,
it is not broken, and it does not need fixing.  Leave it there.

				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry


Volume-Number: Volume 11, Number 39