home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.11 / text0040.txt < prev    next >
Encoding:
Text File  |  1987-07-18  |  13.5 KB  |  311 lines
  1. Included below is a draft proposal for IEEE P1003.1 regarding
  2. the recently raised issue of Archive/Data Interchange Format.
  3. I will deliver a proposal resembling it to P1003.1 at their
  4. next meeting, which is three weeks from today, in Seattle.
  5.  
  6. Note two things:  this is a proposal for P1003.1, not P1003.2,
  7. or any other group; if you disagree with my conclusions, you
  8. can submit your own proposal-- the address is below.
  9.  
  10. If you agree with my approach but think it needs adjusting,
  11. you can send me mail or submit articles.  If you disagree, you
  12. can also do those things.
  13.  
  14.  
  15.  
  16.                                   tar vs. cpio      IEEE P1003.1 N.___
  17.                                                            1 June 1987
  18.  
  19.                                John S. Quarterman
  20.  
  21.                     Institutional Representative from USENIX
  22.                                    usenix!jsq
  23.  
  24.  
  25.  
  26.           Secretary, IEEE Standards Board
  27.           Attention: P1003 Working Group
  28.           345 East 47th St.
  29.           New York, NY 10017
  30.  
  31.           In both the Trial Use Standard and Draft 10, POSIX sS10.1
  32.           describes a data interchange format based on the tar
  33.           program.  That section has appeared in every draft of IEEE
  34.           1003.1 in some form and has always been based on tar format.
  35.           The P1003.1 Working Group has recently received two related
  36.           proposals regarding that section: one to add cpio format
  37.           (including old-style, non-ASCII (non c option) format);
  38.           <N.048 Lorraine C. Kevra> <V11N14> <V11N25 Eric S. Raymond>
  39.           the other to replace the existing tar-based format with cpio
  40.           format.  <N.043 X/OPEN> <V11N13> Some clarifications were
  41.           received to the former.  <N.064 Dominic Dunlop> <V11N15> It
  42.           was also proposed verbally in the latest Working Group
  43.           meeting to drop sS10.1 altogether and let P1003.2 handle the
  44.           issue.  <V11N08> <V11N11> <V11N09 Guy Harris> <V11N12 Doug
  45.           Gwyn>
  46.  
  47.           The present note is a response to those proposals.  Much of
  48.           the detail in it is derived from articles posted in the
  49.           USENET newsgroup comp.std.unix.  Those articles are
  50.           referenced with this format: <V11N09 Guy Harris> which gives
  51.           the volume (11) and number of the article, and the name of
  52.           the submittor.  If no submittor name is given, the posting
  53.           was by the moderator, John S. Quarterman.  Thanks to those
  54.           who submitted articles.  However, the content of this note
  55.           is solely the responsibility of the author.
  56.  
  57.           There are a number of problems with both cpio formats.
  58.           First, those related to the non-ASCII format:
  59.  
  60.             1.  Numerous parameters, including inode numbers, mode
  61.                 bits, and user and group IDs, are kept in two-byte
  62.                 binary integers.  This has historically produced
  63.                 serious byte-order problems when data is moved among
  64.                 systems with different byte orders.  <V11N09 Guy
  65.                 Harris>
  66.  
  67.             2.  The byte-swapping and word-swapping options to the
  68.                 cpio program are inadequate patches; with an ASCII
  69.                 format the problem would not be present.  The options
  70.                 are not consistent across versions of the program: in
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.           Page 2                  tar vs. cpio      IEEE P1003.1 N.___
  79.  
  80.  
  81.  
  82.                 System III, data blocks and file names are byte
  83.                 swapped; in System V, only data blocks are byte
  84.                 swapped.  <V11N09 Guy Harris>
  85.  
  86.             3.  The two-byte integer format limits the range of inode
  87.                 numbers to 1..65535.  Many current file systems are
  88.                 bigger than that.  <V11N37 Paul Eggert> <V11N39 Henry
  89.                 Spencer>
  90.  
  91.           Non-ASCII cpio format is clearly not portable and should not
  92.           even be considered for standardization.  <V11N12 Doug Gwyn>
  93.  
  94.           There are several problems that occur even with the ASCII
  95.           cpio format:
  96.  
  97.             1.  Many implementations of cpio only look at the lower 16
  98.                 (or even 15) bits of the inode number, even in ASCII
  99.                 format.  <V11N39 Henry Spencer> This is because the
  100.                 variable that is used to contain the value is declared
  101.                 to be unsigned short, just as in binary format.  Thus,
  102.                 even though ASCII cpio format does not constrain this
  103.                 number, it is still less than portable.  <V11N37 Paul
  104.                 Eggert>
  105.  
  106.             2.  The proposed cpio ASCII format as specified, <N.048
  107.                 Lorraine C. Kevra> <V11N14> is not portable because
  108.                 the proposal assumes that sizeof(int) == sizeof(long).
  109.                 <N.064 Dominic Dunlop> <V11N15>
  110.  
  111.             3.  The file type written in a numerical format, making it
  112.                 UNIX specific rather than POSIX specific, since POSIX
  113.                 (and tar) specifies symbolic, rather than numerical,
  114.                 values for file types.  <V11N09 Guy Harris>
  115.  
  116.             4.  Hard links are not handled well, since cpio format
  117.                 does not record that two files are linked.  If two
  118.                 files that are linked are written in cpio format, two
  119.                 copies will be written.  There is an option to the
  120.                 cpio program to detect duplicate files by matching
  121.                 pairs of (h_dev, h_ino) and producing links, but that
  122.                 is done after the fact.  <V11N09 Guy Harris> (There is
  123.                 a program, afio, that handles cpio format more
  124.                 efficiently in this and other cases than the licensed
  125.                 versions of the program.) <V11N21 Chuck Forsberg>
  126.  
  127.             5.  Symbolic links are not handled at all, and no type
  128.                 value is reserved for them.  This makes cpio useless
  129.                 on a large class of historical implementations (those
  130.                 based on 4.2BSD or its file system) for one of the
  131.                 main purposes of POSIX sS10.1: archiving files for
  132.                 later retrieval and use on the same system.
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.           Page 3                  tar vs. cpio      IEEE P1003.1 N.___
  141.  
  142.  
  143.  
  144.             6.  The cpio format is less common than tar format: there
  145.                 are few historical implementations from Version 7 on
  146.                 that do not have tar; there are many that do not have
  147.                 cpio.  <V11N09 Guy Harris> <V11N10 Charles Hedrick>
  148.                 <V11N24 Jim Cottrell> It is true that cpio (non-ASCII
  149.                 format) was invented before tar, <V11N22 Joseph S. D.
  150.                 Yao> apparently in PWB System 1.0.  <V11N26 Joseph S.
  151.                 D. Yao> However, cpio was not available outside AT&T
  152.                 before the release of System III, while tar was in
  153.                 wide use with Version 7 and is still much more common.
  154.                 Also, it appears that the cpio format of PWB was not
  155.                 the same as that of System III.  <V11N39 Henry
  156.                 Spencer> Although System III and perhaps early
  157.                 releases of System V did not include tar, <V11N26
  158.                 Joseph S. D. Yao> current releases of System V do.
  159.  
  160.             7.  It is very late in the process to propose that P1003.1
  161.                 adopt cpio format now, especially considering that it
  162.                 was originally proposed to and rejected by the
  163.                 /usr/group committee before P1003.1 was even formed.
  164.                 <V11N39 Henry Spencer>
  165.  
  166.           There are several advantages to the current tar-based format
  167.           as specified in sS10.1:
  168.  
  169.             1.  There are no byte- or word-swapping issues caused by
  170.                 the format, since all the header values are ASCII byte
  171.                 streams.  <V11N17 John Gilmore>
  172.  
  173.             2.  There are no inode numbers recorded, and file types
  174.                 are kept in symbolic form, so the format is less
  175.                 implementation-specific than cpio format.  <V11N17
  176.                 John Gilmore>
  177.  
  178.             3.  Historical tar format is the most widely used, as
  179.                 discussed in 6. above, despite apparent assertions to
  180.                 the contrary.  <N.043 X/OPEN> <V11N13>
  181.  
  182.             4.  The format specified in sS10.1 is upward-compatible
  183.                 with tar format.  Old tar archives can be extracted by
  184.                 a program that implements sS10.1.  Archives using some
  185.                 of the extensions of sS10.1 can be extracted with old
  186.                 (Version 7) tar programs, although symbolic links will
  187.                 not be extracted and contiguous files will not be
  188.                 handled properly (cpio does not handle these
  189.                 capabilities at all).  Files with very long names will
  190.                 not be handled properly (cpio does no better at this).
  191.                 All tar implementations are compatible to this extent.
  192.                 <V11N17 John Gilmore>
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.           Page 4                  tar vs. cpio      IEEE P1003.1 N.___
  203.  
  204.  
  205.  
  206.             5.  The /usr/group working group and P1003.1 have already
  207.                 done the work <P.061> <M.019 5.1.121 Pg.13> <RFC.003
  208.                 #121> <P.038> <P.006> required to add optional
  209.                 extensions (such as symbolic links, contiguous files,
  210.                 and long file names) that are needed on many
  211.                 historical implementations and that cpio format lacks.
  212.  
  213.             6.  The format is extensible for future facilities.
  214.                 <V11N39 Henry Spencer>
  215.  
  216.             7.  There is a public domain implementation of the format
  217.                 of sS10.1.  That implementation provided feedback which
  218.                 led to improvements in the current specification, and
  219.                 has been in use for years in transferring data with
  220.                 licensed tar implementations.  <V11N17 John Gilmore>
  221.  
  222.             8.  Many people prefer the user interface of the cpio
  223.                 program to that of the tar program, because the former
  224.                 can accept a list of pathnames to archive on standard
  225.                 input while the latter takes them as arguments,
  226.                 limiting the length of the list.  <V11N34 Andrew
  227.                 Tannenbaum> However, the above-mentioned public domain
  228.                 implementation of tar accepts pathnames on standard
  229.                 input.  <V11N17 John Gilmore> <V11N19 Jim Cottrell>
  230.                 Diffs to standard tar to add an option to accept
  231.                 pathnames on standard input when creating an archive
  232.                 have also been posted to USENET.  <V11N36 John
  233.                 Gilmore> The user interface is, in any case,
  234.                 irrelevant to P1003.1.  <V11N39 Henry Spencer> <V11N40
  235.                 Rahul Dhesi>
  236.  
  237.           There are some problems that neither tar nor cpio handles
  238.           well.
  239.  
  240.             1.  An option to prevent crossing mount points would be
  241.                 useful for backups.  <V11N19 Jim Cottrell> <V11N22
  242.                 Joseph S. D. Yao> However, this appears to be more of
  243.                 an implementation issue than a format issue, <V11N28
  244.                 Dave Brower> <V11N32 Joseph S. D. Yao> especially
  245.                 considering that there are options to find in 4.2BSD,
  246.                 <V11N24 Jim Cottrell> SunOS 3.2, <V11N36 John Gilmore>
  247.                 and System V Release 3.0 <V11N35 Mike Akre> that take
  248.                 care of this.
  249.  
  250.             2.  The default block size in many tar implementations is
  251.                 too large for some tape controllers to read <V11N27
  252.                 Rob Lake> (the 3B20 has this problem).  This is not a
  253.                 problem with the interchange format, however.
  254.  
  255.           There is nothing that the proposed cpio can handle that the
  256.           tar-based format already in POSIX sS10.1 cannot handle; in
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.           Page 5                  tar vs. cpio      IEEE P1003.1 N.___
  265.  
  266.  
  267.  
  268.           fact, the former is less capable.  If cpio format were
  269.           augmented to handle missing capabilities, it would be
  270.           subject to the same objections now aimed at the format given
  271.           in sS10.1: that it was not identical with an existing format.
  272.  
  273.           There is no advantage in replacing the current tar-based
  274.           format of sS10.1 with cpio format.  There is also no
  275.           advantage in adding cpio format, because two standards are
  276.           not as good as a single standard.
  277.  
  278.           Some have recommended removing sS10.1 from POSIX altogether,
  279.           <V11N12 Doug Gwyn> perhaps with a recommendation for P1003.2
  280.           to pick up the idea.  <V11N09 Guy Harris> While I believe
  281.           that that would be preferable to adding cpio format, whether
  282.           or not tar format remains, I recommend leaving sS10.1 as it
  283.           is, because
  284.  
  285.              o+ The inclusion of an archive/interchange file format is
  286.                in agreement with the purpose of POSIX to promote
  287.                portability of application programs across interface
  288.                implementations.  Some format will be used.  It is to
  289.                the advantage of the users of the standard for there to
  290.                be a standard format.
  291.  
  292.              o+ The de facto standard is tar format.  The current sS10.1
  293.                standardizes that, and provides upward-compatible
  294.                extensions in areas that were previously lacking.
  295.  
  296.           The Archive/Interchange File Format should be left as it is.
  297.  
  298.                                                   Thank you,
  299.  
  300.  
  301.  
  302.                                                   John S. Quarterman
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309. Volume-Number: Volume 11, Number 41
  310.  
  311.