home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.11 / text0053.txt < prev    next >
Encoding:
Internet Message Format  |  1987-07-18  |  3.6 KB

  1. From: seismo!munnari!yabbie.oz!rcodi (Ian Donaldson)
  2.  
  3. In article <8208@ut-sally.UUCP>:
  4. > From: MIKEMAC%UNBMVS1.BITNET@wiscvm.wisc.edu (Michael MacDonald)
  5. >     I have just finished working on a CPIO tape reader and approx 1 year
  6. > ago a TAR tape reader for our IBM3090 180/vf running MVS/XA.
  7.  
  8. Sounds reasonable.  About the same time it would seem, I wrote an implementation
  9. of Tar in Pascal under NOS on a Cyber 170, with 60-bit words.  See comments
  10. below.
  11.  
  12. > #define PFXSIZ    155
  13. >     char    prefix[PFXSIZ];
  14. > which is used when name isn't big enough.  The total of the two is set
  15. > to match the minimum permissible value of PATH_MAX.  -mod ]
  16.  
  17. I don't agree - there should be no limit to the pathname size.
  18. 4.2bsd has a limit of MAXPATHLEN (unfortunately), but it is a reasonable
  19. value (1024).  Probably the reason that was enforced was a side-effect
  20. of the speedups to nami(), using one copyinstr() rather than judicious use
  21. of fubyte().  The code could be tweaked to overcome this limit without
  22. too much trouble no doubt.  V7 and SVR2 don't have any such limit.
  23.  
  24. 100+155 just doesn't seem enough in comparison for Tar, but in practice
  25. it would suffice 99% of the time.
  26.  
  27. >        4)  All of the tape drives that I have worked with (not that many)
  28. >            are capable of writing a short block. If TAR would recognize
  29. >            a physical end of file rather than two blocks of hex 00's.
  30. >            This would solve a number of problems with TAR.
  31.  
  32. Yes, but tar is not always used with tapes, and is not always used
  33. with machines that have 8-bit bytes (eg: Cyber).  
  34.  
  35. I have often written tar archives to raw disk partitions.  If you were 
  36. to use the OS EOF concept here, it would fail miserably since the archive 
  37. is only a fraction of the size of the partition usually. 
  38.  
  39. The implementation of Tar I had on the Cyber worked well but it it would have 
  40. been much more complicated to make it recognize a physical EOF half way through
  41. a 60-bit word (yes there are 7.5 8-bit bytes/60 bit word, and thats
  42. how they arrive from the tape-drives or disks).  NOS does provide a
  43. rather perverted way of determing how many unused bits are in the last
  44. word, but that information is typically only available to the assembly
  45. language programmer, or system guru, and is device dependent.
  46.  
  47. Remember that tar and cpio work with any "file" that you tell them to.
  48. They are not hard-coded for tapes.
  49.  
  50. >        5)  Limited amount of Unix dependent information in the header.
  51. >            If a *backup* system is used for data interchange is it really
  52. >            necessary to add many Operating System dependent features.
  53.  
  54. Yes, but remember this is a UNIX archive mechanism.  Thus it should be able
  55. to save/restore files on most UNIX systems.  It was not designed for
  56. other operating systems.  Information that is not common to most
  57. implementations of UNIX is probably not worth putting in the header.
  58. Those implementations that don't support such information can safely
  59. ignore it anyway.
  60. There is no such information there at the moment in Tar headers.
  61. There is an inode/dev pair in cpio's header however, but this is used
  62. for link determination at extract time.
  63.  
  64. [ We are discussing standardizing a data interchange/archive format 
  65. in a standard that its authors explicitly wanted to be implementable
  66. on hosted, i.e., non-UNIX-based, systems.  The inclusion of inode
  67. numbers is a problem for such implementations, especially when it
  68. is not necessary, as demonstrated by the tar format.  -mod ]
  69.  
  70. >    CPIO Format comments.
  71. >         1)  Data is not block oriented. This slows down processing
  72. >             considerably.
  73.  
  74. Its a time/space tradeoff.
  75.  
  76. Ian D.
  77.  
  78.  
  79. Volume-Number: Volume 11, Number 54
  80.  
  81.