🚀 go-pugleaf

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