NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/std/unix/350

Internet Message Format | 1992-07-28 | 3.8 KB

Path: sparky!uunet!uunet!not-for-mail
From: [e-mail] (Leslie Mikesell)
Newsgroups: comp.std.unix
Subject: Re: Your chance to contribute to new POSIX archive format
Date: 29 Jul 1992 00:28:09 -0700
Organization: Chinet - Public Access UNIX
Lines: 79
Sender: [e-mail]
Approved: [e-mail] (Moderator, Sean Eric Fagan)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
NNTP-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]

Submitted-by: [e-mail] (Leslie Mikesell)

In article <[e-mail]> [e-mail] (Peter da Silva) writes:
>Submitted-by: [e-mail] (Peter da Silva)

>I'm not familiar with the ISO1001 format, but I would like to suggest a textual
>self-documenting format, like RFC822. You don't need to put the actual field
>names in every file header if you establish a property file at the beginning of
>the archive. For example:
>    FieldCodeset: ASCII
>    FieldSeparator: <0A>
>[ these two would be required for the initial header, and need to be in an
>  agreed on language. ]

What's a field?  And why so verbose in something that will only be
parsed by programs or people who better know what they are doing?
How about short abbreviations for the common header items?

>    HeaderLength: 96
>    BodyLength: 0
>    Common: HeaderLength,BodyLength,FileName,ModificationTime,Owner
>[ This establishes the common fields until the next Common field ]
>    2746
>    13995
>    usr/local/src/pax/Makefile
>    19920723.194516.0001
>    peter
>[ 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?  If you don't repeat the token for each item, how will you recover
from errors where the initial description is lost?

I agree with the concept though.  We should only need one format for
encapsulating any attributes that any OS might need to carry around
if it is done with header records that can be added as necessary.
Textual components can be noted as such for conversion as necessary
to extract on any other system.  Other data types can be identified
to the extent possible and the type of encoding/encryption/compression
can be noted per-item.  Using a mailable encoding should produce a
mailable archive (i.e. the header fields should be textual).

>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.

>>     - 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.

>>         - Compression of individual files in the archive

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.

>>         - Direct mailability of the archive file (without translation,
>>           such as through uuencode)

This should be a possibility by using an appropriate encoding but not
enforced for backup media.   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.

Les Mikesell
  [e-mail]

Volume-Number: Volume 28, Number 65