🚀 go-pugleaf

From: davidsen@steinmetz.uucp (William E. Davidsen Jr)

In article <8208@ut-sally.UUCP>:
>From: MIKEMAC%UNBMVS1.BITNET@wiscvm.wisc.edu (Michael MacDonald)
>   TAR Format comments.
I realize this hasn't stopped some people, but I will pass on tar
comments because I'm not an expert.

>
>   CPIO Format comments.
>        1)  Data is not block oriented. This slows down processing
>            considerably.
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.

>        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).

>        3)  Is 128 that much better than 100? See TAR note 3.
Although I've never been bitten by this, it could be a problem. I'm not
sure that it justified scrapping a format which is widely used. cpio
does allow dumping from a relative directory if you have a system with
pathnames longer than the files.

>        4)  The CPIO end of file mark (TRAILER!!!) why not a physical EOF
>            See TAR note 4.
cpio will run nicely to other media sice as floppy disk and/or
removable disk packs. Most device drivers don't support any EOF on
these other than the physical size of the media. You can also have
multiple cpio dumps on a single file, although this is most useful when
doing incremental backups.

>        5)  When it comes to OS dependent information the CPIO header is
>            full of it.
We *are* talking about a U*IX standard here. For data interchange
between unlike systems we have the ANSI standard for tapes, which has
been around since at least 1975 because I wrote a driver for it on a
custom o/s. In FORTRAN. Yes, barf!
[ See comments in previous article about what IEEE 1003.1 is. -mod ]

>        6)  After writing the CPIO tape reader I came across a ?serious?
>            problem. (The following note is from the unix manual page cpio(4)
>            The h_name field is "h_namesize rounded to word" long. The
>            header must begin on a word boundary (although not documented).
>            The wordsize of the machine is not a CPIO option (as far as I can
>            tell). This means CPIO tapes cannot be read on a machine with
>            a different wordsize. I question if this "feature" should be
>            standardized without at least a wordsize option.
I confess I don't understand the wording here, but cpio is *not*
limited in this way as far as I can tell. I routinely transfer files
from Xenix (16 bit) to PC/IX (16 bit), to VAX, Sun3, and unix-pc (all
32 bit), and from time to time Cray2 (64 bit). It all works, so I think
the wording is at fault here, not the method.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {chinet | philabs | sesimo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

Volume-Number: Volume 11, Number 56