home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.11 / text0065.txt < prev    next >
Encoding:
Internet Message Format  |  1987-07-18  |  2.9 KB
  1. From: ka@hropus.UUCP (Kenneth Almquist)
  2.  
  3. > [ We are discussing standardizing a data interchange/archive format
  4. > in a standard that its authors explicitly wanted to be implementable
  5. > on hosted, i.e., non-UNIX-based, systems.  The inclusion of inode
  6. > numbers is a problem for such implementations, especially when it
  7. > is not necessary, as demonstrated by the tar format.  -mod ]
  8.  
  9. Several people have suggested that tar's method of handling links is
  10. better than cpio's.  After looking at the tar format, I wondered how
  11. tar could possibly handle links correctly.   A quick experiment showed
  12. that it doesn't.  Try the following:
  13.  
  14.     > file1
  15.     ln file1 file2
  16.     tar -cf archive file1 file2
  17.     rm file1 file2
  18.     tar -xf archive file2
  19.  
  20. The second tar command will fail because tar will simply try to create
  21. a link from file1 to file2, but since I only requested that file2 be
  22. extracted file1 does not exist.
  23.  
  24. I claim that this is a bug in the tar archive format rather than just
  25. the tar program.  Consider what tar must do to function correctly.  Tar
  26. could remember the location of file1 and lseek to it in this particular
  27. example, but in general the input to tar is not a regular file and thus
  28. may not be seekable.  The best bug fix that I could come up with is to
  29. to make tar write the contents of all files that it does not extract
  30. to a temporary file.  This is unsatisfactory because a user who tried
  31. to extract a single file from a 32 megabyte tape would almost certainly
  32. run out of disk space.
  33.  
  34. So it seems to me that tar cannot be made to handle links correctly
  35. unless the tar archive format is changed.  The cpio format, on the other
  36. hand, allows links to be handled correctly.  The fact that cpio includes
  37. inode numbers is not all that major a problem for non-UNIX based systems.
  38. Since the only thing the inode numbers are used for is resolving links,
  39. a system which does not support (non-symbolic) links can leave garbage
  40. in the inode field when writing tapes.  A system which does have links
  41. but does not have inode numbers can use a sequence number in place of
  42. the inode number.
  43.  
  44. I recognize that users will very rarely encounter this bug in tar, but
  45. I still view it as a serious problem in a *standard*.  The question is
  46. not whether this bug in tar desperately needs to be fixed (which is
  47. doesn't), but whether it is reasonable to expect vendors selling cpio
  48. to deliberately introduce a bug into cpio.  Unless someone can suggest
  49. a good way to make cpio use the tar format and still work correctly,
  50. vendors will have to do just that to be compatible with the new standard.
  51.  
  52.  
  53. I wonder if there is still any chance of a new interchange format that
  54. corrected the deficiencies of both cpio and tar being accepted as the
  55. standard.  Assuming someone could be found to write a public domain
  56. implementation of the new format, would that be sufficient to make it
  57. a reasonable alternative to the existing implementations?
  58.                 Kenneth Almquist
  59.  
  60. Volume-Number: Volume 11, Number 66
  61.  
  62.