home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.11 / text0088.txt < prev    next >
Encoding:
Internet Message Format  |  1987-07-18  |  4.1 KB
  1. From: ka@gatech.UUCP@opus.uucp (Kenneth Almquist)
  2.  
  3. OK, here is a simple, backward compatible fix to the tar format.  When
  4. tar encounters a file name which is a link to a file that it previously
  5. dumped, it should first write out a header for the file indicating that
  6. it is a link to a previously dumped file.  It should then write out
  7. another header for the file, this time without linkflag set, and follow
  8. this header with the contents of the file.  This way, if the first link
  9. to a file is not dumped, its contents will be available later when
  10. subsequent links are dumped.
  11.  
  12. This is backward compatible because an old version of tar would make the
  13. link when it read the first header, and then dump the contents of the
  14. file when it read the second header.  Dumping the contents of the file
  15. does no harm because is will not modify the contents of the file.  Of
  16. course, new implementations of tar might want to recognize this situation
  17. and avoid dumping the contents of the file, but only for reasons of
  18. efficiency.
  19.  
  20. I noted Marc Mengel's suggestion that tar write out the contents of a file
  21. when the last link to a file is encountered, rather than the first.  This
  22. would be nice, but I don't see how it could be done in a way that is
  23. backward compatible with the current tar format.  I also read Michael
  24. Gersten's article suggesting that tar could rewind raw magnetic tapes by
  25. closing them and openning them again.  This proposal doesn't deal with
  26. the question of how cpio could be made to use the tar format, since cpio
  27. reads from its standard input, which it has no way of closing and openning
  28. again, and it also ignores the case where tar is reading from a pipe
  29. because the tape drive is not on the same machine that tar is running on.
  30. So I feel that the above change to the tar format is necessary.
  31.  
  32. The remaining problem with the tar format is the limit on the file name
  33. size.  If memory serves, cpio originally limited file names to 127 char-
  34. acters, and this was recognized as inadequate and increased to 255 char-
  35. acters.  The current maximum file name in tar is 99 characters.
  36.  
  37. However, the maximum file name supported by tar can be increased while
  38. still allowing files whose names are not more than 99 characters long to
  39. be read by existing implementations.  I will suggest one possibility here.
  40. Increase the size of the linkname field to 200 characters.  Since this
  41. field is at the end of the header structure, this will not alter the
  42. location of any of the other fields.  Place a 100 character name exten-
  43. tion field after the linkname field.  If the file name field does not
  44. contain a nul terminator, the remainder of the file name is assumed to
  45. be in the file name extention field.  This scheme allows file names of
  46. up to 199 characters to represented, which comes close to the 255
  47. character limit of the current cpio implimentation.  It leaves 55 bytes
  48. of the header free for future expansion.
  49.  
  50. These changes to the tar format would make it possible to write a program
  51. which used the tar format, but otherwise behaved exactly like cpio except
  52. for a slight decrease in the maximum file name length.
  53.  
  54. I still don't like it, mind you.  I receive a lot more programs over the
  55. net than I do via tape, and here tar fails miserably because it has nul
  56. characters in the header which news and mail programs cannot handle.  It
  57. is hard to get excited over a standard that fails to handle the most
  58. common case (or more accurately, what is the most common case for me).
  59. But I agree with Henry Spencer's statement that the role of standards
  60. committees should be to standardize existing practice, with at most minor
  61. changes.  So we should either forget about developing a standard now, or
  62. standardize on the most widely available format (which is tar) after fixing
  63. the major problems with it.  I could go for either approach.
  64.                 Kenneth Almquist
  65.  
  66. P.S.  A lot of nonsense has appeared in this group about the supposed
  67.       deficiencies of cpio, which I won't rebut since I don't support
  68.       using the cpio format as a standard.  Just please take it all with
  69.       a grain of salt.
  70.  
  71. [ I'd rather have details than innuendo, thanks.  -mod ]
  72.  
  73. Volume-Number: Volume 11, Number 89
  74.  
  75.