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: <8296@ut-sally.UUCP>
Date: Wed, 17-Jun-87 16:30:39 EDT
Article-I.D.: ut-sally.8296
Posted: Wed Jun 17 16:30:39 1987
Date-Received: Mon, 22-Jun-87 02:08:57 EDT
References: <8188@ut-sally.UUCP> <8208@ut-sally.UUCP>, <8251@ut-sally.UUCP>
Sender: std-unix@ut-sally.UUCP
Reply-To: henry@utzoo.UUCP (Henry Spencer)
Lines: 25
Approved: jsq@sally.utexas.edu (Moderator, John Quarterman)

From: henry@utzoo.UUCP (Henry Spencer)

> >        1)  Data is not block oriented. This slows down processing...
> I miss this one. It may slow things under MVS, but there's no reason
> why reading less physical data should slow things down. Quite the
> opposite.

The problem being alluded to is that the data is not block-aligned.  This
is a bit of a performance pain when the disks are block-aligned, although
tar's block alignment isn't going to help a lot if the disk blocks are bigger
than tar's (which they normally are, nowadays).

> >        2)  There is no room left in the header. No customization
> >            possible (without also sending the customized program).
> This is a major advantage. Save us from "custom standard' format. The
> custom stuff belongs in the *file*, not the format (in my opinion).

The point here is that you can customize tar to some degree *without*
making it incompatible with the standard ones.  (We did, for example.)
This is not true of cpio, since there's no spare space in the header.

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

Volume-Number: Volume 11, Number 69