home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.28 / text0063.txt < prev    next >
Encoding:
Text File  |  1992-08-17  |  3.3 KB  |  81 lines
  1. Submitted-by: les@chinet.chi.il.us (Leslie Mikesell)
  2.  
  3. In article <152l4tINNist@ftp.UU.NET> peter@ferranti.com (Peter da Silva) writes:
  4. >Submitted-by: peter@ferranti.com (Peter da Silva)
  5.  
  6. >I'm not familiar with the ISO1001 format, but I would like to suggest a textual
  7. >self-documenting format, like RFC822. You don't need to put the actual field
  8. >names in every file header if you establish a property file at the beginning of
  9. >the archive. For example:
  10. >    FieldCodeset: ASCII
  11. >    FieldSeparator: <0A>
  12. >[ these two would be required for the initial header, and need to be in an
  13. >  agreed on language. ]
  14.  
  15. What's a field?  And why so verbose in something that will only be
  16. parsed by programs or people who better know what they are doing?
  17. How about short abbreviations for the common header items?
  18.  
  19. >    HeaderLength: 96
  20. >    BodyLength: 0
  21. >    Common: HeaderLength,BodyLength,FileName,ModificationTime,Owner
  22. >[ This establishes the common fields until the next Common field ]
  23. >    2746
  24. >    13995
  25. >    usr/local/src/pax/Makefile
  26. >    19920723.194516.0001
  27. >    peter
  28. >[ These are the header length, body length, filename, etcetera for the first
  29. >  file ]
  30.  
  31. What's the advantage of this over explicit token/value pairs for each header
  32. item?  If you don't repeat the token for each item, how will you recover
  33. from errors where the initial description is lost?  
  34.  
  35. I agree with the concept though.  We should only need one format for
  36. encapsulating any attributes that any OS might need to carry around
  37. if it is done with header records that can be added as necessary.
  38. Textual components can be noted as such for conversion as necessary
  39. to extract on any other system.  Other data types can be identified
  40. to the extent possible and the type of encoding/encryption/compression
  41. can be noted per-item.  Using a mailable encoding should produce a
  42. mailable archive (i.e. the header fields should be textual). 
  43.  
  44. >This should require a minimal amount of additional space, and would be
  45. >indefinitely extensible. Older versions of the archive program could
  46. >discard unknown headers, or stick them in a file somewhere for later
  47. >messing around with.
  48.  
  49. Not only older versions will have to deal with this but versions under
  50. different OS's that don't have the same storage concepts. 
  51.  
  52. >>     - The archive must be able to be stored on as many media types
  53. >>       as possible, including but not limited to 9-track and streaming 
  54. >>       tape, diskette, CDROM, ftp files, etc.
  55.  
  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. >>         - Compression of individual files in the archive
  61.  
  62. Yes, and the compression should restart as you go to new media to allow
  63. the above splitting to work, or the header should note that the file
  64. can only be extracted as a continuation.
  65.  
  66. >>         - Direct mailability of the archive file (without translation,
  67. >>           such as through uuencode)
  68.  
  69. This should be a possibility by using an appropriate encoding but not
  70. enforced for backup media.   For backup purposes the archiver should
  71. be able to note the current contents of directories and which of those
  72. items are included in the archive (like GNU tar with the -G option).
  73. This allows restoring incremental backups without accumulating the
  74. files that were deleted between the runs.
  75.  
  76. Les Mikesell
  77.   les@chinet.chi.il.us
  78.  
  79. Volume-Number: Volume 28, Number 65
  80.  
  81.