home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.11 / text0033.txt < prev    next >
Encoding:
Internet Message Format  |  1987-07-18  |  4.1 KB
  1. From: trb@ima.ISC.COM (Andrew Tannenbaum)
  2.  
  3. I don't have Section 10 of the POSIX Trial Use Standard, but I am
  4. interested in what happens to tar and cpio in POSIX.
  5.  
  6. I see that the netnews discussion of this has been partly a
  7. popularity contest between tar and cpio.  There are more
  8. important issues to discuss than people's provincial biases.  If
  9. you come from BSD land, you probably like tar.  If you come from
  10. AT&T land, you probably like cpio.
  11.  
  12. I have some comments about cpio, since it is my personal favorite.
  13. They apply to both the file format and to the program function.
  14. Some comments apply to tar as well.
  15.  
  16. I like the idea of cpio taking a list of files on stdin.  I wish
  17. tar had this option.  tar cv `find / -print | fgrep -v -f except.file`
  18. doesn't cut it.
  19.  
  20. [ Evidently John Gilmore's public domain implementation that he
  21. posted to comp.sources has this.  I know of no proprietary version
  22. that does.  -mod ]
  23.  
  24. cpio's binary format should have been killed off long ago.
  25. cpio has a 'portable' format, which still has several problems:
  26.  
  27. -       Byte swapping and its friends.
  28.     There are systems which swap bytes and/or halfwords.  There are
  29.     even systems which xor 0 and 1 bits on tapes.  If CPIO
  30.     wrote a magic number 0x12345678 in the header, it could resolve
  31.     these problems painlessly.
  32.  
  33. -       I agree that the binary cpio header is silly.
  34.     The portable header is all printable ASCII data, but the
  35.     filename is terminated by a null, which makes it harder to play
  36.     with the archive.  Here is a shar-like program which makes a
  37.     cpio archive which can unpack itself.
  38.  
  39. <<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>>
  40. #! /bin/sh
  41. # take a list of files on stdin and make them into a bundle which
  42. # can be passed through sh to extract them.
  43. cat << \!
  44. #!/bin/sh
  45. # cpio archive
  46. (read a; read a; read a; read a; cat) < $0 | cpio -icdm 
  47. exit
  48. !
  49. cpio -oac
  50. <<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>>
  51.  
  52.     As I recall, it can have problems because of the fact that the
  53.     filename is null-terminated, like if you try to read its
  54.     output into a mail message with an editor.  It would also be
  55.     neighborly if the ASCII header was more human readable, a space
  56.     or carriage return here or there wouldn't hurt at all.
  57.  
  58.     I realize that this is a standardization effort, but if you are
  59.     going to enhance the format for some portability reason, you
  60.     might want to consider my enhancement suggestions.
  61.  
  62. -       The familiar problems with damaged archives should be
  63.     fixed (Out of phase--get help).
  64.  
  65. -    There are systems which need to extend the archive
  66.     formats in local ways, for instance, to add extra mode
  67.     information for a secure UNIX implementation, or file type
  68.     information when the UNIX system deals with other types of file
  69.     systems.  It would be very useful to have a compatible way to
  70.     extend the header such that any system could check the local
  71.     field and either use or ignore the information.  Right
  72.     now, there is little hope for compatibility, the only
  73.     solutions I can think of (various kinds of shadow files
  74.     which contain mode info) are quite kludgy.
  75.  
  76. -       These programs should deal with multiple tape archives
  77.     in a standard way.  I have seen many local hacks to do
  78.     this.
  79.  
  80. -       Blocksizes for speed, space, and streaming efficiency are best
  81.     handled by blocking filters rather than by hacks like -B.  I
  82.     have heard of ctccpio, but can only worry about what it
  83.     actually is.  How many programs are going to have to have
  84.     knowledge about how many goofy devices?  I don't understand why
  85.     cpio has to know anything about a device.  This is UNIX, isn't
  86.     it?  Which brings us back to the question of multi-tape
  87.     archives, maybe the blocking filter should also handle the
  88.     multi-tape problem?  This means lots of data travels over a
  89.     pipe.  Modern OS's should be able to do something smart here.
  90.     (The multi-tape question leaves me with a queasy feeling.)
  91.  
  92. I would like to see a discussion about tar and cpio rather than
  93. opinions about which is better.  I am particularly concerned about
  94. extending the header format to deal with atypical file types.
  95.  
  96.     Andrew Tannenbaum   Interactive   Boston, MA   +1 617 247 1155
  97.  
  98. Volume-Number: Volume 11, Number 34
  99.  
  100.