home *** CD-ROM | disk | FTP | other *** search
- Submitted-by: peter@ferranti.com (Peter da Silva)
-
- In article <155ha9INNlrq@ftp.UU.NET> les@chinet.chi.il.us (Leslie Mikesell) writes:
- > What's a field?
-
- A "line", "entry", ... (shut up, Data).
-
- Also, someone noted in Email that a third entry for block size (so you could
- pad the headers and data blocks for easy DMA-ing if you wanted to) would be
- desirable.
-
- > And why so verbose in something that will only be
- > parsed by programs or people who better know what they are doing?
-
- Good point. The final form would obviously want to be shorter. I wouldn't
- want to fix the size of tags or anything, or make them unintelligable.
- With the "common" headers the size of tags is pretty unimportant.
-
- Another comment in Email was that the "common" fields should be delimited
- and left as prefixes, so you could so something like:
-
- Common:@FileName:/usr/peter/tosave@
-
- And leave off common sections of filenames and things.
-
- > >[ These are the header length, body length, filename, etcetera for the first
- > > file ]
-
- > What's the advantage of this over explicit token/value pairs for each header
- > item?
-
- Space saving.
-
- > If you don't repeat the token for each item, how will you recover
- > from errors where the initial description is lost?
-
- Good point. You could periodically repeat the common description, perhaps,
- or if you're really unsure about the media just leave it off altogether. Or
- you could try and figure it out from context... one of the points to this
- format is that you would have a reasonable chance of doing that.
-
- > >This should require a minimal amount of additional space, and would be
- > >indefinitely extensible. Older versions of the archive program could
- > >discard unknown headers, or stick them in a file somewhere for later
- > >messing around with.
-
- > Not only older versions will have to deal with this but versions under
- > different OS's that don't have the same storage concepts.
-
- Yes, I think I referenced that in my example with the FileComment field.
- Shoudl definitely be made explicit, though.
-
- >
- > >> - The archive must be able to be stored on as many media types
- > >> as possible, including but not limited to 9-track and streaming
- > >> tape, diskette, CDROM, ftp files, etc.
- >
- > One thing that is needed here is to be able to generate multi-part
- > archives, possibly spliting files across media, with the ability
- > to extract files from any single part directly.
-
- That's a good point. How about this:
-
- FileName: /usr/lib/news/history
- Segment: 2/6
- Offset: 10485532
-
- > Yes, and the compression should restart as you go to new media to allow
- > the above splitting to work, or the header should note that the file
- > can only be extracted as a continuation.
-
- Good.
-
- > This should be a possibility by using an appropriate encoding but not
- > enforced for backup media.
-
- This could be a compression option:
-
- Compression: UUENCODE
-
- (expansion, really. :->) If it offends, leave it implicit.
-
- > For backup purposes the archiver should
- > be able to note the current contents of directories and which of those
- > items are included in the archive (like GNU tar with the -G option).
- > This allows restoring incremental backups without accumulating the
- > files that were deleted between the runs.
-
- Good.
- --
- Peter da Silva `-_-'
- $ EDIT/TECO LOVE 'U`
- %TECO-W-OLDJOKE Not war? Have you hugged your wolf today?
- Ferranti Intl. Ctls. Corp. Sugar Land, TX 77487-5012 +1 713 274 5180
-
-
- Volume-Number: Volume 28, Number 69
-
-