home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.28 / text0067.txt < prev    next >
Encoding:
Text File  |  1992-08-17  |  3.5 KB  |  99 lines

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