Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!ut-sally!std-unix
From: std-unix@ut-sally.UUCP
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Message-ID: <8249@ut-sally.UUCP>
Date: Mon, 8-Jun-87 09:22:36 EDT
Article-I.D.: ut-sally.8249
Posted: Mon Jun  8 09:22:36 1987
Date-Received: Sun, 14-Jun-87 18:40:44 EDT
References: <8188@ut-sally.UUCP> <8208@ut-sally.UUCP>
Reply-To: seismo!munnari!yabbie.oz!rcodi (Ian Donaldson)
Organization: RMIT Comm & Elec Eng, Melbourne, Australia.
Lines: 81
Approved: jsq@sally.utexas.edu (Moderator, John Quarterman)
Summary: don't like this physical eof business

From: seismo!munnari!yabbie.oz!rcodi (Ian Donaldson)

In article <8208@ut-sally.UUCP>:
> From: MIKEMAC%UNBMVS1.BITNET@wiscvm.wisc.edu (Michael MacDonald)
> 
>     I have just finished working on a CPIO tape reader and approx 1 year
> ago a TAR tape reader for our IBM3090 180/vf running MVS/XA.

Sounds reasonable.  About the same time it would seem, I wrote an implementation
of Tar in Pascal under NOS on a Cyber 170, with 60-bit words.  See comments
below.
 
> #define PFXSIZ	155
> 	char	prefix[PFXSIZ];
> 
> which is used when name isn't big enough.  The total of the two is set
> to match the minimum permissible value of PATH_MAX.  -mod ]

I don't agree - there should be no limit to the pathname size.
4.2bsd has a limit of MAXPATHLEN (unfortunately), but it is a reasonable
value (1024).  Probably the reason that was enforced was a side-effect
of the speedups to nami(), using one copyinstr() rather than judicious use
of fubyte().  The code could be tweaked to overcome this limit without
too much trouble no doubt.  V7 and SVR2 don't have any such limit.

100+155 just doesn't seem enough in comparison for Tar, but in practice
it would suffice 99% of the time.

>        4)  All of the tape drives that I have worked with (not that many)
>            are capable of writing a short block. If TAR would recognize
>            a physical end of file rather than two blocks of hex 00's.
>            This would solve a number of problems with TAR.

Yes, but tar is not always used with tapes, and is not always used
with machines that have 8-bit bytes (eg: Cyber).  

I have often written tar archives to raw disk partitions.  If you were 
to use the OS EOF concept here, it would fail miserably since the archive 
is only a fraction of the size of the partition usually. 

The implementation of Tar I had on the Cyber worked well but it it would have 
been much more complicated to make it recognize a physical EOF half way through
a 60-bit word (yes there are 7.5 8-bit bytes/60 bit word, and thats
how they arrive from the tape-drives or disks).  NOS does provide a
rather perverted way of determing how many unused bits are in the last
word, but that information is typically only available to the assembly
language programmer, or system guru, and is device dependent.

Remember that tar and cpio work with any "file" that you tell them to.
They are not hard-coded for tapes.

>        5)  Limited amount of Unix dependent information in the header.
>            If a *backup* system is used for data interchange is it really
>            necessary to add many Operating System dependent features.

Yes, but remember this is a UNIX archive mechanism.  Thus it should be able
to save/restore files on most UNIX systems.  It was not designed for
other operating systems.  Information that is not common to most
implementations of UNIX is probably not worth putting in the header.
Those implementations that don't support such information can safely
ignore it anyway.
There is no such information there at the moment in Tar headers.
There is an inode/dev pair in cpio's header however, but this is used
for link determination at extract time.

[ We are discussing standardizing a data interchange/archive format 
in a standard that its authors explicitly wanted to be implementable
on hosted, i.e., non-UNIX-based, systems.  The inclusion of inode
numbers is a problem for such implementations, especially when it
is not necessary, as demonstrated by the tar format.  -mod ]

>    CPIO Format comments.
>         1)  Data is not block oriented. This slows down processing
>             considerably.

Its a time/space tradeoff.

Ian D.


Volume-Number: Volume 11, Number 54