home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.11 / text0016.txt < prev    next >
Encoding:
Internet Message Format  |  1987-07-18  |  2.6 KB
  1. From: gnu@hoptoad.UUCP (John Gilmore)
  2.  
  3. I don't know anybody who's ever had trouble reading a tar tape
  4. (assuming their hardware could read the medium).  I've heard of plenty
  5. of troubles with cpio transfers, including the byte swap issues
  6. mentioned so well by Guy, but also the fact that there are two formats
  7. and one of them is inherently nonportable (and happens to be the
  8. default) causes no end of confusion for users just trying to get their
  9. data from here to there.  All versions of tar are compatible.
  10. When researching tar for my implementation, I tracked down various
  11. reports of tar tapes that could not be read by other tars, and all
  12. turned out to be pilot error.  (Laura says she's heard of problems
  13. when reading long-filename tapes on short-filename systems, but
  14. cpio is no better at this, and I hear that V8 tar has been fixed to
  15. rename long-name files while extracting them.)
  16.  
  17. Laura Creighton, sitting next to me, remembers that she had to rewrite
  18. cpio several times when trying to read tapes sent from AT&T people
  19. to her.  On utzoo, a V7 Unix system, there was no cpio, but she had
  20. access to versions on other U of T machines.  She recalls things like
  21. the PWB cpio writing tapes that could not be read by System III, and
  22. System III writing tapes that could not be read by some releases of
  23. System V, but without a lot of research she can't document these
  24. claims.  (Anybody else out there run into this more recently?)
  25.  
  26. After looking at the cpio record format typed in by John, it looks like
  27. it is a lot more Unix file system specific than tar, e.g. what are
  28. inode numbers doing on a portable transfer format?  Also, the inode
  29. numbers are defined to be unsigned shorts (or 6-digit octal) while in
  30. many Unix systems, inode numbers are 32 bits long and will not fit in
  31. this format.  Of course the binary format should not even be mentioned
  32. in the standard, since an "unsigned short" has no portable
  33. representation, but it's clear that the octal form is not big enough,
  34. so what do we do?  Define a new standard "almost like current cpio" but
  35. incompatible?  Let's stick with tar -- it doesn't expose the innards
  36. of the V7 file system, and it works.
  37.  
  38. There is the additional advantage of a public domain implementation of
  39. the proposed tar standard (written by me, available from mod.sources),
  40. which also served to work out several bugs in the proposal.  This
  41. implementation has been exchanging data with real source licensed Unix
  42. tar's for years now without trouble.  It also implements some of the
  43. things that cpio can do that Unix tar can't; in particular, reading the
  44. list of files to be archived or extracted from standard input.
  45.  
  46.  
  47. Volume-Number: Volume 11, Number 17
  48.  
  49.