Further development of the format?

[Midar]

Since I recently wrote my own Zoo implementation and added it to both ObjFW and ofarc, I was wondering if further development of the format is planned and there might be things I should add in the future? For example, support for files > 4 GB?

Furthermore I was wondering if there are any plans to release a bunch of .zoo files for compatibility testing. I created a bunch of my own using the original zoo + using my own implementation and tried extracting them with the other implementation.

[troglobit]

I am not the original author of zoo. I sometimes restore old programs for use on Linux and UNIX systems.

The only plan I have for this project is to make it work with modern compilers and on 64-bit systems.

However, I do not have the time to work on it presently.

[johnsonjh]

I'd like to see some extensions to the format, but they should be done in a way that don't massacre compatibility and degrade gracefully with existing implementations of archivers.

[Midar]

Unfortunately the Zoo format is not a very good one. It doesn't have any kind of extensions like ZIP or LHA do, so whatever we do needs to be coordinated by all Zoo implementations. Are there any that are still active other than this repo and ObjFW? I didn't know about this repo when I started mine, or the public domain release - I was under the assumption there was no open source implementation.

If it's just these two, I propose to use this bug to extend the format and coordinate.

The main problem is that we have offsets of 32 bit everywhere. So we cannot possibly create something fully backwards compatible. The closest we could do is the following:

• Extend the archive header to type 2. This is a type 1 header followed by a uint32 that contains the upper 32 bit of the 64 bit offset of the data start. If the data starts within the 32 bit offset, it can be used by old versions, if it's bigger, we definitely need a newer version supporting this.
• Similarly for the directory entry: There, we could keep type 2, but use the variable area to add 5 uint32s:
  • The upper 32 bit of the 64 bit next header offset
  • The upper 32 bit of the 64 bit data offset
  • The upper 32 bit of the uncompressed size
  • The upper 32 bit of the compressed size
  • The upper 32 bit of the comment offset
• This means that all files where the upper 32 bit are 0 still remain compatible with older versions, but as soon as something is out of the 4 GB limit, an old implementation can't extract it. But, again, there is no way around this.

Thoughts?