View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0038143||FPC||Packages||public||2020-11-27 21:36||2020-11-28 18:29|
|Reporter||Antonio Ramírez||Assigned To||Michael Van Canneyt|
|Fixed in Version||3.3.1|
|Summary||0038143: Zipper doesn't work when trying to decompress certain files that work in other applications.|
|Description||When trying to unzip certain files an EConvertError exception is raised due to parts of the date being out of range. Those files present no problems when dealt with using other applications such as 7-Zip.|
A patch to fix the problem is attached.
|Steps To Reproduce||Try to decompress the attached "pasbroken.zip" with a TUnzipper, an EConvertError will be raised.|
|Tags||No tags attached.|
|Fixed in Revision||47618|
pasbroken.zip (86,954 bytes)
zipper.diff (601 bytes)
diff -C 3 C:/FPC/3.2.0/source/packages/paszlib/src/zipper.pp C:/Users/Bloodbat/Documents/projects/Lazarus/zdoomexecutor/src/zipper.pp *** C:/FPC/3.2.0/source/packages/paszlib/src/zipper.pp Wed Feb 12 03:19:25 2020 --- C:/Users/Bloodbat/Documents/projects/Lazarus/zdoomexecutor/src/zipper.pp Fri Nov 27 14:14:48 2020 *************** *** 849,855 **** --- 849,857 ---- Y:=((ZD shr 9) and 127)+1980; if M < 1 then M := 1; + if M > 12 then M := 12; if D < 1 then D := 1; + if D > 31 then D := 31; DT:=ComposeDateTime(EncodeDate(Y,M,D),EncodeTime(H,N,S,MS)); end;
zipper.diff (601 bytes)
looks like M is the only one in trouble here.
S:=(ZT and 31) shl 1;
N:=(ZT shr 5) and 63;
H:=ZT shr 11;
D:=ZD and 31;
M:=(ZD shr 5) and 15; <<<<<<<<<<<< could generate more than 12
Y:=((ZD shr 9) and 127)+1980;
if M < 1 then M := 1;
if D < 1 then D := 1;
maybe a MOD operator would work better ?
there must be a reason its like that ?
||I don't think a mod operator is the correct solution, nor is my patch: when decompressing the posted sample zip file the month is calculated as 13, the correct number should be 8, but both solutions at least enable it to open valid zip files. Upon looking at the other variables, parts of the code are also wrong: for the attached sample zip file minutes should be 45, while the code results in 40, the hours and year are off as well. (The day and seconds are correct).|
||After inverting the parameters to ZipDateTimeToDateTime the header for the test file I posted here decodes correctly; after looking at another file created by the same application I noticed the dates were completely out of whack, probably due to the same issue, I created several files with another application and those headers decode as they should, so this is probably an issue with the creating application ignoring endianness, despite zip headers supposedly being little endian. This report should be ignored and closed. Sorry.|
Things that come to my mind:
- What do the other zip generate as date?
- what if M=6 and D=31 which is still an illegal date, since june only has 30 days?
I made the algorithm more robust. Some more corrections are done,
and if after that it is still an incorrect date/time the current date/time are substituted for date/time parts.
||Fixed in my tests with the latest code.|
|2020-11-27 21:36||Antonio Ramírez||New Issue|
|2020-11-27 21:36||Antonio Ramírez||File Added: pasbroken.zip|
|2020-11-27 21:36||Antonio Ramírez||File Added: zipper.diff|
|2020-11-28 00:12||jamie philbrook||Note Added: 0127220|
|2020-11-28 00:13||jamie philbrook||Note Edited: 0127220||View Revisions|
|2020-11-28 10:08||Antonio Ramírez||Note Added: 0127226|
|2020-11-28 11:02||Antonio Ramírez||Note Added: 0127230|
|2020-11-28 11:46||Marco van de Voort||Note Added: 0127232|
|2020-11-28 14:30||Michael Van Canneyt||Assigned To||=> Michael Van Canneyt|
|2020-11-28 14:30||Michael Van Canneyt||Status||new => resolved|
|2020-11-28 14:30||Michael Van Canneyt||Resolution||open => fixed|
|2020-11-28 14:30||Michael Van Canneyt||Fixed in Version||=> 3.3.1|
|2020-11-28 14:30||Michael Van Canneyt||Fixed in Revision||=> 47618|
|2020-11-28 14:30||Michael Van Canneyt||FPCTarget||=> 3.2.2|
|2020-11-28 14:30||Michael Van Canneyt||Note Added: 0127236|
|2020-11-28 17:35||Antonio Ramírez||Note Added: 0127244|
|2020-11-28 18:29||Antonio Ramírez||Status||resolved => closed|
|2020-11-28 18:29||Antonio Ramírez||Note Added: 0127246|