This specification defines the implementation of ZIP archives as used by the RVZstd standard. This standard is RomVault's implementation of deterministic ZIP archives compressed with zstd.

The data compression must be exactly zstd version 1.5.5 using level 19 without long distance matching, training, or any-other parameters altered. All files and empty directories must be compressed with the zstd method, which is method 93.

The ZIP file comment in the End of Central Directory is used to check the validity of the RVZstd file.

The comment must be formatted as the 15 bytes of RVZSTD-XXXXXXXX. The XXXXXXXX is the CRC32 of the central directory records stored as hexadecimal upper case text. (The CRC32 of the bytes in the file between SOCD & EOCD)

This comment ensures that if any change is made to the files within the zip this checksum will no longer match the byte data in the central directory, and in this way we can check the validity of an RVZstd file.

The filenames of the compressed files in a zip archive are stored in the local header and the central directory as byte arrays. Zip was original built on early IBM PCs, and as such uses code page 437 to convert a string to a byte array to store the filenames. With the arrival of Unicode, multiple different methods were added to the official zip format to permit Unicode filenames to be stored in a zip file. RVZstd format uses the general purpose bit 11 method. So to store a filename in an RVZstd zip file you must first see if the filename can be stored using code page 437, if not then UTF-8 encoding should be used in the byte arrays, this is then indicated by setting bit 11 of the General Purpose Bit Flags both in the local header and central directory.

For the creation of consistent RVZstd files, the file order is also very important. Files must be sorted by filename using a lower case sort.

As zips only store files (not directories), files in directories are represented by storing a relative path to the filename. For example file test1.rom in directory set1 would be stored with a filename of set1/test1.rom. Some zipping programs will store this as set1\test1.rom.

This leads to a possible naming inconsistency. The zip file format states: “All slashes should be forward slashes ‘/’ as opposed to backwards slashes ‘\’”. So RomVault will change all \ characters to /. This must be done before sorting, to ensure that the sort is performed correctly.

A directory entry is stored in a zip by adding a file entry ending in a directory separator character with a zero size and CRC. So directory set1 would be stored as a zero length, zero CRC file called set1/. Some zip programs when adding the previously mentioned file set1/test1.rom will also add the directory set1/, this creates an inconsistency problem. In this example the set1/ directory entry is unnecessary, as the filename set1/test1.rom implies the existents of the set1/ directory. To resolve this inconsistency un-needed directories should be removed from the zip, the only needed directory entries are empty directories that are not implied by any file entries.

Example:

The set1/ entry should be removed, as it is implied by the set1/test1.rom file. The set2/ entry should be kept to create the empty directory, as removing it would completely remove the set2 directory.

Another test that could be performed is checking for repeat file entries inside the zip, most zip programs have a hard time handling this and will just ignore this repeat giving the user no way of knowing there is a repeat filename problem. So it would fix another possible inconsistency if RVZstd scanning at least warned about repeat filename being found inside a zip.

• Official ZIP file specification
• zstd compression