Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: cameron@elecvax.oz (Cameron Simpson)
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Message-ID: <8359@ut-sally.UUCP>
Date: Sun, 21-Jun-87 17:41:40 EDT
Article-I.D.: ut-sally.8359
Posted: Sun Jun 21 17:41:40 1987
Date-Received: Tue, 30-Jun-87 06:46:25 EDT
Sender: std-unix@ut-sally.UUCP
Reply-To: cameron@elecvax.oz (Cameron Simpson)
Lines: 33
Approved: jsq@sally.utexas.edu (Moderator, John Quarterman)

From: cameron@elecvax.oz (Cameron Simpson)

>From: ka@hropus.UUCP (Kenneth Almquist)
>Subject: Re: tar vs. cpio
>Message-ID: <8276@ut-sally.UUCP>
>
>[ example of failure of tar's format ]
>
>So it seems to me that tar cannot be made to handle links correctly
>unless the tar archive format is changed.  The cpio format, on the other
>hand, allows links to be handled correctly.  The fact that cpio includes
>inode numbers is not all that major a problem for non-UNIX based systems.
>Since the only thing the inode numbers are used for is resolving links,
>a system which does not support (non-symbolic) links can leave garbage
>in the inode field when writing tapes.  A system which does have links
>but does not have inode numbers can use a sequence number in place of
>the inode number.

Please, monotonic garbage! Imagine extracting such a tape on a system
which *does* support (non-symbolic) links. I can easily envisage an
implementation which simply did not initialise the garbage, and wrote
said garbage the same for each file. On extraction you'd end up with a
single file with LOTS of links!-)
	- Cameron Simpson

ACSnet:	cameron@elecvax.eecs.unsw.oz	JANET: elecvax.eecs.unsw.oz!cameron@ukc
CSNET:	cameron@elecvax.oz		BITNET:	cameron%elecvax.oz@CSNET-RELAY
ARPA:	cameron%elecvax.eecs.unsw.oz@seismo.css.gov
UUCP:	...!seismo!munnari!elecvax.eecs.unsw.oz!cameron
     or	munnari!elecvax.eecs.unsw.oz!cameron@seismo.css.gov


Volume-Number: Volume 11, Number 77