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 vs. cpio
Message-ID: <8363@ut-sally.UUCP>
Date: Tue, 23-Jun-87 20:56:19 EDT
Article-I.D.: ut-sally.8363
Posted: Tue Jun 23 20:56:19 1987
Date-Received: Tue, 30-Jun-87 07:17:43 EDT
References: <8188@ut-sally.UUCP> <8208@ut-sally.UUCP> <8249@ut-sally.UUCP>, <8276@ut-sally.UUCP>
Sender: std-unix@ut-sally.UUCP
Reply-To: henry@utzoo.UUCP (Henry Spencer)
Lines: 30
Approved: jsq@sally.utexas.edu (Moderator, John Quarterman)

From: henry@utzoo.UUCP (Henry Spencer)

> ... A system which does have links
> but does not have inode numbers can use a sequence number in place of
> the inode number.

Suppose it wants to use a sequence number that is bigger than 16/18 (16
for binary cpio format, 18 for ASCII cpio format) bits?  For that matter,
what if *inode* numbers are bigger than that?  This argument would be a
whole lot stronger if the cpio formats (note plural) left more room for
this particular magic cookie.

> I wonder if there is still any chance of a new interchange format that
> corrected the deficiencies of both cpio and tar being accepted as the
> standard...

Not unless there were truly overwhelming technical reasons for picking it.
Even the cpio formats, scummy though they are, are readily readable without
new software at a great many existing sites.  The same is true of tar on an
even larger scale.  A new format would start from zero... not an attractive
proposition.  I would also observe that we don't *want* the sort of format
that a standards committee would invent -- have you studied, say, X.400
lately?  Better to pick the best of existing practice and standardize that,
possibly with minor changes.  That is what standards committees are really
supposed to do.

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

Volume-Number: Volume 11, Number 80