home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / std / unix / 354 < prev    next >
Encoding:
Internet Message Format  |  1992-07-30  |  4.0 KB
  1. Path: sparky!uunet!uunet!not-for-mail
  2. From: peter@ferranti.com (Peter da Silva)
  3. Newsgroups: comp.std.unix
  4. Subject: Re: Your chance to contribute to new POSIX archive format
  5. Date: 30 Jul 1992 23:32:27 -0700
  6. Organization: Xenix Support, FICC
  7. Lines: 97
  8. Sender: sef@ftp.UU.NET
  9. Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
  10. Message-ID: <15amprINNrsd@ftp.UU.NET>
  11. References: <14q4alINNate@ftp.UU.NET> <152l4tINNist@ftp.UU.NET> <155ha9INNlrq@ftp.UU.NET>
  12. NNTP-Posting-Host: ftp.uu.net
  13. X-Submissions: std-unix@uunet.uu.net
  14.  
  15. Submitted-by: peter@ferranti.com (Peter da Silva)
  16.  
  17. In article <155ha9INNlrq@ftp.UU.NET> les@chinet.chi.il.us (Leslie Mikesell) writes:
  18. > What's a field?
  19.  
  20. A "line", "entry", ... (shut up, Data).
  21.  
  22. Also, someone noted in Email that a third entry for block size (so you could
  23. pad the headers and data blocks for easy DMA-ing if you wanted to) would be
  24. desirable.
  25.  
  26. > And why so verbose in something that will only be
  27. > parsed by programs or people who better know what they are doing?
  28.  
  29. Good point. The final form would obviously want to be shorter. I wouldn't
  30. want to fix the size of tags or anything, or make them unintelligable.
  31. With the "common" headers the size of tags is pretty unimportant.
  32.  
  33. Another comment in Email was that the "common" fields should be delimited
  34. and left as prefixes, so you could so something like:
  35.  
  36.     Common:@FileName:/usr/peter/tosave@
  37.  
  38. And leave off common sections of filenames and things.
  39.  
  40. > >[ These are the header length, body length, filename, etcetera for the first
  41. > >  file ]
  42.  
  43. > What's the advantage of this over explicit token/value pairs for each header
  44. > item?
  45.  
  46. Space saving.
  47.  
  48. > If you don't repeat the token for each item, how will you recover
  49. > from errors where the initial description is lost?  
  50.  
  51. Good point. You could periodically repeat the common description, perhaps,
  52. or if you're really unsure about the media just leave it off altogether. Or
  53. you could try and figure it out from context... one of the points to this
  54. format is that you would have a reasonable chance of doing that.
  55.  
  56. > >This should require a minimal amount of additional space, and would be
  57. > >indefinitely extensible. Older versions of the archive program could
  58. > >discard unknown headers, or stick them in a file somewhere for later
  59. > >messing around with.
  60.  
  61. > Not only older versions will have to deal with this but versions under
  62. > different OS's that don't have the same storage concepts. 
  63.  
  64. Yes, I think I referenced that in my example with the FileComment field.
  65. Shoudl definitely be made explicit, though.
  66.  
  67. > 
  68. > >>     - The archive must be able to be stored on as many media types
  69. > >>       as possible, including but not limited to 9-track and streaming 
  70. > >>       tape, diskette, CDROM, ftp files, etc.
  71. > 
  72. > One thing that is needed here is to be able to generate multi-part
  73. > archives, possibly spliting files across media, with the ability
  74. > to extract files from any single part directly.   
  75.  
  76. That's a good point. How about this:
  77.  
  78.     FileName: /usr/lib/news/history
  79.     Segment: 2/6
  80.     Offset: 10485532
  81.  
  82. > Yes, and the compression should restart as you go to new media to allow
  83. > the above splitting to work, or the header should note that the file
  84. > can only be extracted as a continuation.
  85.  
  86. Good.
  87.  
  88. > This should be a possibility by using an appropriate encoding but not
  89. > enforced for backup media. 
  90.  
  91. This could be a compression option:
  92.  
  93.     Compression: UUENCODE
  94.  
  95. (expansion, really. :->) If it offends, leave it implicit.
  96.  
  97. > For backup purposes the archiver should
  98. > be able to note the current contents of directories and which of those
  99. > items are included in the archive (like GNU tar with the -G option).
  100. > This allows restoring incremental backups without accumulating the
  101. > files that were deleted between the runs.
  102.  
  103. Good.
  104. -- 
  105. Peter da Silva                                               `-_-'
  106. $ EDIT/TECO LOVE                                              'U` 
  107. %TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
  108. Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180
  109.  
  110.  
  111. Volume-Number: Volume 28, Number 69
  112.