From: Eric Backus Subject: Re: Status of list To: dj AT ctron DOT com Date: Wed, 5 Aug 92 11:01:41 PDT Cc: lwj AT cs DOT kun DOT nl, djgpp AT sun DOT soe DOT clarkson DOT edu Mailer: Elm [revision: 66.25] > unzip includes the following lines in the copyright: > > > Copyright in unzip.c, originally from unzip version 1.2 (?): > > > > * Copyright 1989 Samuel H. Smith; All rights reserved > > * > > * Do not distribute modified versions without my permission. > > * Do not remove or alter this notice or any other copyright notice. > > * If you use this in your own program you must distribute source code. > > * Do not use any of this in a commercial product. > > The fourth one hurts. Besides, .zip format doesn't support (1) > storing empty directories, (2) supporting binary vs text files, (3) > arbitrary comments and descriptions, (4) renaming files as they're > added, and (5) the ability to prompt for continuation in the middle of > the extraction. I also intend to support multiple floppy extraction > and unix dd floppies. Unless you distribute unzip with djgpp, you are not using unzip in a commercial product. So I don't believe the above copyright should be a problem. The copyright on the zoo archiver is more explicit - it applies only to the source code of the zoo archiver itself. You might check it out. As an alternative to zip or zoo, you could use something like tar or cpio to make archives, and use compress or freeze to compress the archives. You'll probably end up with better compression in the process, since you're compressing the whole thing at once. As to your five objections: 1. I agree that a decent archiver should handle empty directories, and zip and zoo currently do not. I guess that's one reason to switch to cpio or tar. Are there any empty directories in the djgpp distribution? 2. I think an archiver should store exactly what you give it. If you want to convert the format of a text file, use a program that is made to do that. Thus, I don't think text vs. binary should be an issue for an archiver. 3. Arbitrary comments and descriptions can be placed in a file, and the file placed in the archive. Why should an archiver have to do any more than this? 4. Rename as files are added. I guess I don't see why you'd want to do this, but I agree that existing archivers can't do it. Most will allow an individual file to be extracted to standard output, so you can send it to whatever file you want, but that would be tedious to do for many files. 5. Sounds like you want to split an archive up on multiple floppies, without having to put it together on a hard disk first. This would be nice, and is not available from most archivers. But I do okay with split to split up a big archive, and cat to put it together. -- Eric Backus ericb%hplsla AT hplabs DOT hp DOT com (206) 335-2495