trrntzipui []

This is an old revision of the document!

Update History for Trrntzip.UI & Trrntzip.NET.exe Both C# implementations of trrntzip format.

Latest versions available here : https://www.romvault.com/trrntzip/

Trrntzip update history
2020-11-26	Another edge case ZIP64 bug was found where a file is added to a zip that is initially bigger that 4Gb but compresses down to less than 4Gb. (In this case the total zip filesize is less than 4Gb.) The local header for the compressed file does correctly contain ZIP64 extensions, as does the central directory. But also in this case zip64 End of Central Directory information and End Of Central Directory Locator information was being stored in the zip file. This was done because there is a file containing ZIP64 extension information. This turns out to be incorrect as the rules to add these extra ZIP64 locators are: If the start of the central dir in the file is greater than 4Gb into the file. If the size of the central dir is itself greater than 4Gb in size. If there are more than 65536 files contained within the zip file. None of these cases are met in this file and so the extra ZIP64 locator information should not be in the file. This has now been corrected. (Interesting side note, is that WINRAR V5.91 also make this same error in the file.)
2020-11-26	Further investigation into unicode filename support showed the change made in 2019-06-11 was still incorrect. APPNOTE.TXT APPENDIX D - Language Encoding, states that zip filenames use IBM's Code Page 437 to store filenames, any character not in this code page should be treated as unicode, a change has been made to the trrntzip format to store filenames using Code Page 437 if possible, otherwise the zip unicode filename extension is used to store the full unicode filename.
2020-03-13	An edge case error was found in the code that could produce a corrupt zip file. It occurred where a files uncompressed size was just under the zip64 4Gb size limit, but its compressed size actually got just a little larger and pushed it over the zip64 4Gb limit making the file require a zip64 local header, because at the time of writing the local header the compressed size was not know, and the uncompressed file was less then 4Gb it was assumed the header did not need the zip64 information added (which was incorrect). A fix was made at this time to check the compressed size to see if it was now larger that 4Gb and if so the local header was extended to add the zip64 information. (This involves pushing the full 4Gb+ of compressed data a few bytes further down the file, to make space for this extra zip64 data in front of this in the local file header.)
2019-06-11	Unicode filenames had previously be added to trrntzip format, initial implementation was any character value less that 256 was considered ASCII and any characters equal and above 256 where concidered UNICODE and if UNICODE was found the zip file would need a UNICODE stored filename, this release change the format to be any character over 127 was considered UNICODE
2018-07-18	C# code updated to support zip64 format

First Trrntzip.exe was C code developed by 'shindakun' available here: https://sourceforge.net/p/trrntzip/code

C Code Trrntzip history
2012-02-02	Zip64 support added by 'ackmed'
2012-01-03	Fixed the directory separator character to be '/'. See 4.4.17 in APPNOTE.TXT
2012-01-03	Fixed Inconsistency in trrntzip files from having un-needed directories in the zip. The new rule was added to only have directory entries in a zip files if the directory is empty.
2007-05-09	First code commit. (by shindakun)

The TorrentZipped Files Comments

The .ZIP file comments in the End of Central directory is used to check the validity of the torrentzipped file.

The comment must be formatted as the 22 bytes of TORRENTZIPPED-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 Start Of Central Directory & End Of Central Directory)

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 a torrentzip file.

File Order with a TorrentZip

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

Directory separator character

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 state “All slashes should be forward slashes ‘/’ as opposed to backwards slashes ‘\’ “. So Torrentzip will change all ‘\’ character to ‘/’. (This must be done before sorting, to ensure that the sort is performed correctly.)

Directory Entries and Empty Directories

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:

Filename	Size	CRC
set1/	0	00000000
set1/test1.rom	1024	53AC4D0
set2/	0	00000000

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.

Latest ZIP files format specifications can be found here https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT