home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.12 / text0009.txt < prev    next >
Encoding:
Text File  |  1989-01-07  |  4.4 KB  |  115 lines
  1. Phone: +44 1 251 2128
  2. Telex: 295467 inset g
  3. From: Jim R Oldroyd <mcvax!inset!jr@seismo.css.gov>
  4.  
  5. [ This has been a bit delayed due to miscommunication.  -mod ]
  6.  
  7. I would like to present a number of points regarding CPIO which I
  8. feel are relevant to the ongoing discussion concerning a Data
  9. Interchange Format for the POSIX 1003.1 standard.
  10.  
  11. I shall correct a number of important points regarding the CPIO
  12. format; points which have been incorrectly stated in recent articles.
  13.  
  14. 1.  At no time has a proposal been made to standardise the binary
  15.     cpio format.  Only the `cpio -c' format is under consideration.
  16.  
  17. 2.  The `cpio -c' format is widely in use in Europe for both Data
  18.     Interchange and Archival purposes.  It's widespread use can
  19.     be attributed, in part, to its endorsement by the X/OPEN Group.
  20.  
  21. 3.  Only one version of the `cpio -c' format is currently in use.
  22.     It is this format being proposed for standardisation.
  23.  
  24. 4.  The `cpio -c' header is written entirely in character form.
  25.     No numerical information is stored in machine-dependent binary
  26.     form.
  27.  
  28. 5.  The `cpio -c' format is capable of archiving and restoring
  29.     all POSIX file types: directories, block special files,
  30.     character special files, regular files and fifos.
  31.  
  32. 6.  The `cpio -c' format can handle pathnames up to 256 bytes.
  33.     This is the length guaranteed on all POSIX systems.
  34.  
  35. 7.  The `cpio -c' format is in the public domain.  (See X/OPEN
  36.     Portability Guide, Volume 2, cpio(4)).
  37.  
  38. 8.  Inode numbers are not recorded.  Symbolic values (derived from a 
  39.     file's inode and device numbers) are stored in the header
  40.     block.  These values are used solely for hard link resolution.
  41.  
  42. 9.  File types are stored in symbolic form.  Symbols are derived from
  43.     historical UNIX file type values.  There is room for 64
  44.     file types; currently only 5 are supported.
  45.  
  46. A number of points have recently been raised as drawbacks of CPIO.
  47. These points seem to be problems with a particular implementation
  48. of a cpio utility.  As the characteristics of the utility are not
  49. relevant for 1003.1, I present only a short summary of points:
  50.  
  51.     - file names are terminated by '\0'
  52.         This is normal UNIX practice for string termination
  53.         and applies to TAR (and USTAR) equally.  On CPIO,
  54.         the '\0' is redundant information and need not
  55.         be interpreted as the file name length is also provided.
  56.  
  57.     - the user interface is less convenient
  58.         This is subjective; many people feel that the
  59.         opposite is true.  The user interface is easily
  60.         alterable (discuss with 1003.2).
  61.  
  62.     - file name size is 128 bytes
  63.         Wrong!  It is 256; see above.
  64.  
  65.     - cpio header is full of OS dependent information
  66.         Wrong!  All information describes file
  67.         characteristics.  There is no OS dependent
  68.         information.  See point 9, above.
  69.  
  70.     - header must start on a word boundary
  71.         Wrong!  The header is character oriented and
  72.         can be read as individual bytes from the archive.
  73.  
  74.     - format cannot be extended to meet future requirements
  75.         Wrong!  Implementations already exist which can
  76.         archive symbolic links and contiguous files.
  77.         There is far more scope for future extension
  78.         than available in the proposed USTAR format.
  79.  
  80.  
  81. Independent of the archive format used, some guidelines must
  82. be followed to ensure that an archive can be extracted on ANY
  83. POSIX system.  Note that the following are NOT rules for using
  84. cpio; they apply equally well to other interchange formats
  85. if portability across ALL systems is to be achieved:
  86.  
  87.     - only POSIX defined file types should be archived
  88.     - headers should be written in US ASCII character set
  89.     - minumum values in section 2.9 for h_uid, h_gid,
  90.       h_nlinks, etc should not be exceeded
  91.     - no portion of any filename should exceed 14 characters
  92.     - one cpio archive should fit on a single medium
  93.     - only one archive should exist per medium
  94.     - relative pathnames (ie, no leading /) should be used
  95.     - tapes should be written in `raw' mode
  96.     - tapes should be written with 5120 byte blocks
  97.  
  98. Any archive intended for use only between systems supporting
  99. more capabilities than the minimum required by POSIX need
  100. not be so restrictive.
  101.  
  102.  
  103.  
  104. I believe that the `cpio -c' tape format has a number of strong
  105. advantages over both the existing tar and the POSIX extended tar
  106. formats.  The `cpio -c' format handles all POSIX file types
  107. correctly, it has been extended to handle other known file types
  108. and there is adequate opportunity for further extension.
  109.  
  110. Thank you,
  111.     Jim R Oldroyd.
  112.  
  113. Volume-Number: Volume 12, Number 10
  114.  
  115.