trrntzipui
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| trrntzipui [2020/11/18 12:20] – gordonj | trrntzipui [2024/04/10 19:08] (current) – johnsanc | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | Update History for Trrntzip.UI & Trrntzip.NET.exe | + | __**Update History for Trrntzip.UI & Trrntzip.NET.exe |
| + | |||
| + | Latest versions available here : [[https:// | ||
| ^ Trrntzip update history ^^ | ^ 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. [[https:// | ||
| + | |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| | |2018-07-18| C# code updated to support zip64 format| | ||
| - | |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| | ||
| - | |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.)| | ||
| - | |2020-11-xx| Further investigation into unicode filename support showed the change made in 2019-06-11 was still incorrect. [[https:// | ||
| - | |2020-11-xx|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 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.)| | ||
| First Trrntzip.exe was C code developed by ' | First Trrntzip.exe was C code developed by ' | ||
| Line 19: | Line 14: | ||
| ^ C Code Trrntzip history ^^ | ^ C Code Trrntzip history ^^ | ||
| + | |2012-02-02|Zip64 support added by ' | ||
| + | |2012-01-03|Fixed the directory separator character to be '/' | ||
| + | |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)| | |2007-05-09|First code commit. (by shindakun)| | ||
| - | |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.| | ||
| - | |2012-01-03|Also fixed the directory separator character to be '/' | ||
| - | |2012-02-02|Zip64 support added by ' | ||
| - | |||
| - | |||
| - | Latest ZIP files format specifications can be found here [[https:// | ||
trrntzipui.1605730835.txt.gz · Last modified: 2020/11/18 11:20 (external edit)