home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.11 / text0038.txt < prev    next >
Encoding:
Internet Message Format  |  1987-07-18  |  2.2 KB
  1. From: henry@utzoo.uucp (Henry Spencer)
  2.  
  3. Andy's comments about the facilities offered by tar and cpio are worthy
  4. of note, but irrelevant to the P1003.1 issues.  This was actually raised
  5. at the original /usr/group standards meeting when the question of a
  6. standard intercharge format came up:  the facilities offered by the
  7. current programs are quite irrelevant to the choice of format, since
  8. the format does not dictate the user interface.  It is not especially
  9. difficult to write "cpar" or "tpio", to get one user interface with the
  10. other format.
  11.  
  12. I thought the choice of tar by /usr/group was a huge win, and still think
  13. so; the extensions added in the Trial Use Standard strengthen this view.
  14.  
  15. The cpio binary format is a travesty:  unportable, non-extensible (for
  16. example, it is sure that inode numbers are only 16 bits, often not true
  17. today), and generally a mess.  Cpio ASCII format is better, but it still
  18. shares some of these problems, since its field widths are sized to fit
  19. old systems (for example, it can't deal with 32-bit inode numbers either).
  20.  
  21. Furthermore, I would note that at least the cpio binary format, possibly
  22. the ASCII one as well, has existed in two different versions.  People who
  23. claim that cpio is older than tar are half-lying:  the current version of
  24. cpio is not.  I submit that the mere existence of multiple incompatible
  25. versions of the cpio format is a major black mark against it.  Tar format
  26. is virtually universal, with only minor (compatible!) extensions having
  27. been made here and there.
  28.  
  29. Andy makes a good point about extensibility.  The tar format extends
  30. gracefully because it has extra room in its header (which the existing
  31. programs helpfully zero rather than filling with random trash) and in its
  32. file-type code space.  (Note that the Trial Use Standard explicitly
  33. reserves certain type codes for local extensions, and others for future
  34. standards.  Note also that the Trial Use Standard's own extensions are
  35. upward-compatible with the existing format and existing programs.)
  36.  
  37. Chapter 10 of the Trial Use Standard is a valuable part of the standard,
  38. it is not broken, and it does not need fixing.  Leave it there.
  39.  
  40.                 Henry Spencer @ U of Toronto Zoology
  41.                 {allegra,ihnp4,decvax,pyramid}!utzoo!henry
  42.  
  43.  
  44. Volume-Number: Volume 11, Number 39
  45.  
  46.