SAC.DYESGPF@E.ISI.EDU (09/15/88)
Keith, please pass this along to anyone else you thik may be interessed. Having worked with CDOS and an ARC program back in late 1982, I was very suprised by the the decision in the SEA vs PK software case. I totally agree with replacing all the SEA format archives with something else. My question concerns ZOO vs PKpak/unpak. Doesn't the newest PK compression usually result in a smaller achive file than ZOO? Are there any paticular advantages to ZOO that I previously missed? If I remember correctly the PK software is faster and gives a smaller file for the normal mix of documentation, source code and executables, but I may be wrong. It may be that the only reason I started using PK software was that it has been SEA ARC compatable, which would make my preference rather a mute point. Of course, if all the main-frame archives switch to a PK format, that would lend "moral-support" to PK which will really get the folks at SEA steamed (I hope). Which ever way this goes, I am all for using the most effective compression program available in the public/shareware domaine. Al Holecek These are my own opions and are not intended to reflect the position of the United States Air Force or the Department of Defense, etc., etc., etc., etc., et
jrv%sdimax2@MITRE-BEDFORD.ARPA (09/17/88)
My personal preference would be to get the SEA vs PK court decision
reversed. The SIMTEL-20 archives may be fixable by standalone programs
running in the background, but there are .ARC files on millions of
floppy disks, too. Converting them requires manual operations.
If we must change formats, I think we should think about potential improvements.
I would suggest improving the archive itself by:
Including a printable character mode. There are still a lot of
seven bit wide communications channels. It would certainly help if
there was a compressed format that did not require an eight bit
wide path.
Storing full pathnames in addition to file names. This would make
an archive a better backup format. The unpacking program should be
able to use or ignore the pathname.
Allowing longer file names. MS-DOS (and OS/2?) restrict names to
8+3 characters, but UNIX names can be longer.
Including a DES encryption option.
I would also suggest improving the pack/unpack program:
I'd like a program that treats an archive exactly like a subdirectory.
Starting the program would "open" the archive. It would then accept
the standard DOS commands DIR, TYPE, and COPY, except that references to
"current directory" would be interpreted as "this archive", and
references to "parent of this directory" would be interpreted as "the
directory containing this archive". Full pathnames would be treated
as usual.
For example,
UNPAK alpha
starts the program and "opens" alpha.pak (or whatever
extension is chosen)
DIR
lists names and characteristics of files in the archive
DIR *.c
lists names and characteristics of .C files in the archive
DIR ..\*.bat
lists names and characteristics of .BAT files in the directory
containing the archive
COPY ..\*.c
adds to the archive all the .C files in the directory containing
the archive
COPY *.doc ..
unpacks the .DOC files and puts them in the same directory
as the archive
COPY *.com \bin
unpacks the .COM files and puts them in subdirectory \bin
on the current drive
TYPE foo.bar
unpacks the indicated file and displays it on the screen
BYE
closes the archive and terminates the program
Essentially, I'm trying to avoid continually retyping the name of the
program and the name of the archive.
It would also be nice to be able to copy files from one archive into
a second without unpacking in the middle.
There's probably a market for a full-screen point-and-click type
user interface too, but that should be a second program. The primary
program should be restricted to a TTY interface so it's portable.
I think now's the time to comment on these suggestions and bring
up others so the next archive will be not only different but BETTER.
- Jim Van Zandt
... ...-....1200 N81N ............GRIEB@LOCKE.HS.WASHINGTON.EDU (CINDY GRIEB) (09/17/88)
I agree with Jim's idea for improvements to (whatever Archive is chosen).
ESPECIALLY the addition of pathnames. It would certainly facilitate the
use of the Archives in backup.
Cindy GriebWANCHO@SIMTEL20.ARMY.MIL ("Frank J. Wancho") (09/17/88)
My personal preference would be to get the SEA vs PK court decision
reversed.
As I read it, it wasn't a court decision, but similar to, if not the
same as an out-of-court settlement. Thus, there is no court decision
to be reversed and no precedent set (in the case law sense).
I will have a lot more to say later, particularly about trademarks and
the use of alternate compressed file schemes on SIMTEL20.
Note also that much of the functionality you propose for manipulating
such files were developed in the CP/M world years ago for LBR files.
It is interesting to see the same proposed for MSDOS...
--Frankpaula@bcsaic.UUCP (Paul Allen) (09/20/88)
In article <8809161727.AA17804@sdimax2.menet> jrv%sdimax2@MITRE-BEDFORD.ARPA writes: > >My personal preference would be to get the SEA vs PK court decision >reversed. Hear! Hear! > The SIMTEL-20 archives may be fixable by standalone programs >running in the background, but there are .ARC files on millions of >floppy disks, too. Converting them requires manual operations. I'm not converting any of my ~60 floppies full of .ARC files until I have to! >If we must change formats, I think we should think about potential improvements. >I would suggest improving the archive itself by: [a 7-bit ASCII mode for archaic communication channels] Uuencode already does this. [storing full pathnames] ZOO does this. [allowing longer names to support other operating systems] ZOO does this too, and runs on lots of systems. [DES encryption] In your archive program? Wouldn't it be simpler to have a separate encryption utility? >I would also suggest improving the pack/unpack program: [an interactive archive viewer/unpacker, sort of like the -i mode of the Berkeley restore program] Sounds nice. [ability to copy an archive member to a different archive without unpacking] Sounds like feaping creaturism to me! [full-screen point-and-click interface] Yeah! >I think now's the time to comment on these suggestions and bring >up others so the next archive will be not only different but BETTER. > > - Jim Van Zandt > ... ...-....1200 N81N ............ ZOO exists, is portable, has a public format, is free, and does almost everything I want in an archiver. The only thing it lacks is multi-volume capability. It can take a list of filenames on stdin, so if it could only write multiple floppies I could use it to backup my hard disk. Pdtar is also portable, public-domain, and free, but the MSDOS implementation can't do compression. There is a version of pdtar that handles multiple floppies, however! I suggest that we use ZOO. It's better than ARC in several ways and it already exists. [mild flame on] A previous poster stated that ZOO was disqualified because Rahul has restricted it from being distributed by services that charge more than a certain amount per hour. This argument is specious, since nobody is being forced to download ZOO from an expensive service. Another previous poster talked about the formation of a committee to design a new non-ARC archive format. This is foolishness, since ZOO already does what we need, is universally and freely available, is portable, and has a publicly documented format. [flame off] Obviously, I'll use whatever archive format eventually dominates, but it seems to me that Rahul's superior archiver is being discarded simply because of some people's emotional biases. Seems a shame, too. (OK, so maybe I'm all wet! If anybody can explain what's wrong with ZOO, or why some other archiver is better, I'm all ears.) Paul -- ------------------------------------------------------------------------ Paul L. Allen | paula@boeing.com Boeing Advanced Technology Center | ...!uw-beaver!ssc-vax!bcsaic!paula