Path: utzoo!attcan!uunet!wuarchive!udel!new
From: new@udel.EDU (Darren New)
Newsgroups: alt.sources.d
Subject: Re: Unnecessary tar-compress-uuencodes
Message-ID: <24445@estelle.udel.EDU>
Date: 13 Jul 90 13:31:24 GMT
References: <15652@bfmny0.BFM.COM> <3114@psueea.UUCP> <1990Jul10.203015.27282@eci386.uucp> <5256@plains.UUCP> <3124@psueea.UUCP> <1990Jul13.022224.25441@lth.se>
Reply-To: new@ee.udel.edu (Darren New)
Organization: University of Delaware
Lines: 20

This sounds good.  As long as we are playing with "standard" formats,
we might want to consider a new version of UUENCODE that avoids
any characters that are not available in EBCDIC.  I have one that
uses only +-*/ 0-9 A-Z a-z and has checksums on each line.

Other than that, the new shar format looks good.
I would suggest making restrictions on the characters that
can appear in filenames (like 14 chars or less, no spaces,
colons, backslashes, [, ], only one period, no semicolons,
and so on).  These could be enforced by default in the
packer and turned off only after dire warnings.

Incidentally, why Unix octal protection bits?  Why not
  RWED (for read, write, execute, delete) 
or some other non-Unix semantics? If it's going to a
Unix machine, a shell script could be put in the archive 
to properly set the protections. If you need particular
UNIX protections, you probably also need particular owners
and groups and such information would be nice to know for
those not running under UNIX.    -- Darren