home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.11 / text0055.txt < prev    next >
Encoding:
Internet Message Format  |  1987-07-18  |  3.0 KB
  1. From: davidsen@steinmetz.uucp (William E. Davidsen Jr)
  2.  
  3. In article <8208@ut-sally.UUCP>:
  4. >From: MIKEMAC%UNBMVS1.BITNET@wiscvm.wisc.edu (Michael MacDonald)
  5. >   TAR Format comments.
  6. I realize this hasn't stopped some people, but I will pass on tar
  7. comments because I'm not an expert.
  8.  
  9. >
  10. >   CPIO Format comments.
  11. >        1)  Data is not block oriented. This slows down processing
  12. >            considerably.
  13. I miss this one. It may slow things under MVS, but there's no reason
  14. why reading less physical data should slow things down. Quite the
  15. opposite.
  16.  
  17. >        2)  There is no room left in the header. No customization
  18. >            possible (without also sending the customized program).
  19. This is a major advantage. Save us from "custom standard' format. The
  20. custom stuff belongs in the *file*, not the format (in my opinion).
  21.  
  22. >        3)  Is 128 that much better than 100? See TAR note 3.
  23. Although I've never been bitten by this, it could be a problem. I'm not
  24. sure that it justified scrapping a format which is widely used. cpio
  25. does allow dumping from a relative directory if you have a system with
  26. pathnames longer than the files.
  27.  
  28. >        4)  The CPIO end of file mark (TRAILER!!!) why not a physical EOF
  29. >            See TAR note 4.
  30. cpio will run nicely to other media sice as floppy disk and/or
  31. removable disk packs. Most device drivers don't support any EOF on
  32. these other than the physical size of the media. You can also have
  33. multiple cpio dumps on a single file, although this is most useful when
  34. doing incremental backups.
  35.  
  36. >        5)  When it comes to OS dependent information the CPIO header is
  37. >            full of it.
  38. We *are* talking about a U*IX standard here. For data interchange
  39. between unlike systems we have the ANSI standard for tapes, which has
  40. been around since at least 1975 because I wrote a driver for it on a
  41. custom o/s. In FORTRAN. Yes, barf!
  42. [ See comments in previous article about what IEEE 1003.1 is. -mod ]
  43.  
  44. >        6)  After writing the CPIO tape reader I came across a ?serious?
  45. >            problem. (The following note is from the unix manual page cpio(4)
  46. >            The h_name field is "h_namesize rounded to word" long. The
  47. >            header must begin on a word boundary (although not documented).
  48. >            The wordsize of the machine is not a CPIO option (as far as I can
  49. >            tell). This means CPIO tapes cannot be read on a machine with
  50. >            a different wordsize. I question if this "feature" should be
  51. >            standardized without at least a wordsize option.
  52. I confess I don't understand the wording here, but cpio is *not*
  53. limited in this way as far as I can tell. I routinely transfer files
  54. from Xenix (16 bit) to PC/IX (16 bit), to VAX, Sun3, and unix-pc (all
  55. 32 bit), and from time to time Cray2 (64 bit). It all works, so I think
  56. the wording is at fault here, not the method.
  57. -- 
  58.     bill davidsen        (wedu@ge-crd.arpa)
  59.   {chinet | philabs | sesimo}!steinmetz!crdos1!davidsen
  60. "Stupidity, like virtue, is its own reward" -me
  61.  
  62. Volume-Number: Volume 11, Number 56
  63.  
  64.