A letter from Gary Conway to Phil Katz. Circa 1988. This letter was recently located amongst some old IDC documents.

Filename : ZIP-FMT2
Revision 1

Phil,

I agree on all of the fields with the exceptions/questions noted at the end of this document.

I would like to add..

File Offset 4 bytes
Entry Status 1 byte deleted,free,used,password
protected, garbled

I personally like the centralized directory format. I propose that we form directory entries just as we had in LBR files, except that we do not require the user to decide apriori how many entries to make. In these entries, I propose that we have a filepointer that is the absolute offset of the subfile within the archive. I believe that this approach will offer much strength against damaged archives. If one subfile is damaged, then we still know exactly where the next one should be. As you have pointed out it might be nice to support a signature (that is larger than 1 byte) that might also aid in recovering damaged files.

I think that the centralized directory would speed up everything we do.

Directory scan -

getting a directory of the archive would be MUCH simpler and MUCH faster since you only have to read the directory portion of the archive and not sequentially scan the whole file.

Extracting/viewing/printing files -

extractions would be faster and lexigraphic insertion would be much easier since you could just merge the old directory with the files to be included in the new directory ahead of time and then just build the new file. It would seem that it would also be a wise idea to use the entry status byte to determine whether or not the file existed in the old archive or if it is a new one to be added. This way we can just add the old directory list and new one together and sort. The status byte would be used at merge time for the arcer to know where to pick up the file, on disk (new one) or out of the old archive.

Regardless of the header location, I believe that we would be wise to include an additional 6 bytes in the header for future expansion(s). Many is the time when I have asked "Have I thought of everything ?" and, of course, ego jumps in and says "of course" , yet later, inevitably, disaster strikes.

We should also provide utilities for globally converting from .ARC format to the new format to encourage SYSOPS to make the jump to the new format, after all, they are the ones we need to sell first.

Phil,

I would like to know more (implementation details) about some of the fields you have proposed, namely..

Bit flag
sequence number (I assume multi-media)
version made by (vendor ID ??)
file type
extra field size

I also feel that using two bytes for the compression version is wasteful when 1 byte will suffice.

Gary Conway, Pres.
Infinity Design Concepts, Inc.