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: <8251@ut-sally.UUCP> Date: Thu, 11-Jun-87 09:28:37 EDT Article-I.D.: ut-sally.8251 Posted: Thu Jun 11 09:28:37 1987 Date-Received: Sun, 14-Jun-87 18:41:15 EDT References: <8188@ut-sally.UUCP> <8208@ut-sally.UUCP> Sender: std-unix@ut-sally.UUCP Reply-To: davidsen@steinmetz.uucp (William E. Davidsen Jr) Organization: General Electric CRD, Schenectady, NY Lines: 62 Keywords: tar cpio Approved: jsq@sally.utexas.edu (Moderator, John Quarterman) 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