TC unable to unpack ZIP containing folder named somethin.lnk

Please report only one bug per message!

Moderators: sheep, Hacker, Stefan2, white

Solf
Junior Member
Junior Member
Posts: 9
Joined: 2010-05-24, 10:51 UTC

TC unable to unpack ZIP containing folder named somethin.lnk

Post by *Solf » 2014-01-31, 09:28 UTC

It looks like TC get confused when trying to unpack such ZIP file and fails with 'disk read error' message.

Sample zip:
https://copy.com/pEgTEa6pwhLXUboM
(right click to download)

Steps:
- Download zip
- Enter zip via Enter
- Try to unpack "TSW Mods.lnk" folder via copy command (F5)

Result: disk read error!

File unpacks just fine with 7zip.

Also you can use TC to RENAME folder name inside zip and then it unpacks via TC just fine.


P.S. Also looks to be an issue with 8.50 RC as well.
Last edited by Solf on 2014-01-31, 11:57 UTC, edited 1 time in total.

User avatar
karlchen
Power Member
Power Member
Posts: 4555
Joined: 2003-02-06, 22:23 UTC
Location: Germany

Post by *karlchen » 2014-01-31, 09:47 UTC

Hello, Solf.

You are sure it is not a problem limited to your sample zip-file?

Which folder tree could hold more .lnk files than the Windows All Users' Start Menu ("C:\ProgramData\Microsoft\Windows\Start Menu")? :wink:
So I zipped the complete subfolder "Start Menu" to "Start Menu.zip" using the Total Commander internal zip function.
Then I went to a different drive and unzipped any part of this "Start Menu.zip" or the whole subfolder "Start Menu" just as I liked. No problem.

Environment:
+ Windows Server 2008 R2 (64-bit)
+ Total Commander 8.50 RC2 (64-bit)

Cheers,
Karl
Linux Mint 19.2 32-bit xfce Desktop, Total Commander 9.22a 32-bit
Haß gleicht einer Krankheit, dem Miserere, wo man vorne herausgibt, was eigentlich hinten wegsollte. (Goethe)

Solf
Junior Member
Junior Member
Posts: 9
Joined: 2010-05-24, 10:51 UTC

Post by *Solf » 2014-01-31, 11:17 UTC

I expect your start menu doesn't contain *FOLDERS* with .lnk extension :)

And zip file unpacks fine with e.g. 7zip so there's certainly problem somewhere in TC zip implementation.

Relation to .lnk folder names is just a strong possibility.

User avatar
MVV
Power Member
Power Member
Posts: 8395
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV » 2014-01-31, 11:25 UTC

I can reproduce bug with attached ZIP using TC 8.50RC2x32 with clean INI: I can't neither extract nor view files inside TSW Mods.lnk folder. Win7x64SP1Pro.
Last edited by MVV on 2014-01-31, 11:45 UTC, edited 1 time in total.

User avatar
white
Power Member
Power Member
Posts: 2020
Joined: 2003-11-19, 08:16 UTC
Location: Netherlands

Re: TC unable to unpack ZIP containing folder with .lnk

Post by *white » 2014-01-31, 11:36 UTC

Solf wrote:It looks like TC get confused when trying to unpack such ZIP file and fails with 'disk read error' message.

Sample zip:
https://copy.com/pEgTEa6pwhLXUboM

....

Also you can use TC to RENAME folder name inside zip and then it unpacks via TC just fine.
Confirmed. Windows XP can unzip the file.

You can simply rename the folder inside the ZIP to the same name. After that TC can unzip the file. Here is what changed:

http://imageshack.com/a/img585/3209/06rm.png (left: file changed by TC, right: original file)

Solf
Junior Member
Junior Member
Posts: 9
Joined: 2010-05-24, 10:51 UTC

Re: TC unable to unpack ZIP containing folder with .lnk

Post by *Solf » 2014-01-31, 11:56 UTC

white wrote: You can simply rename the folder inside the ZIP to the same name. After that TC can unzip the file. Here is what changed:

http://imageshack.com/a/img585/3209/06rm.png (left: file changed by TC, right: original file)
Thanks! A very nice observation.

So the problem possibly is not just name-related, but something deeper -- possibly something about variances in zip file format.

The test file is created by copy.com service so I don't know how exactly it is created.

User avatar
karlchen
Power Member
Power Member
Posts: 4555
Joined: 2003-02-06, 22:23 UTC
Location: Germany

Post by *karlchen » 2014-01-31, 12:27 UTC

Hi, Solf.

OK, differences in the ZIP implementation might be a cause.

Currently I cannot download your testfile, because some security check here won't let me. So I have to create my own test ZIP file. And creating the zip-file will be done by T.C. 8.50 rc2 64-bit, like unzipping.

I added some empty folders to the Start Menu, named
+ foldername1.lnk
+ foldername2.lnk
+ foldername3.lnk

Then again zipped the whole Start Menu folder.
Problem still not reproducible here.

So I assume I will only start seeing the symptoms when I have changed my location and downloaded your test zip-file.

Cheers,
Karl
Linux Mint 19.2 32-bit xfce Desktop, Total Commander 9.22a 32-bit
Haß gleicht einer Krankheit, dem Miserere, wo man vorne herausgibt, was eigentlich hinten wegsollte. (Goethe)

User avatar
white
Power Member
Power Member
Posts: 2020
Joined: 2003-11-19, 08:16 UTC
Location: Netherlands

Post by *white » 2014-01-31, 12:52 UTC

karlchen wrote:Currently I cannot download your testfile..
Here it is.
(BTW. As illustrated above the problem has nothing to do with the folder names.)

Code: Select all

MIME-Version: 1.0
Content-Type: application/octet-stream; name="TSW Mods.lnk.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="TSW Mods.lnk.zip"

UEsDBBQACAgAAHGMPkQAAAAA//////////8yAAAAVFNXIE1vZHMubG5rL0ZsYXNoL0ltcHJvdmVk
VGV4dEZhZGUvQ2hhclByZWZzLmJ4bWxMTVhCAgAAAM0AAAAQAAAAMAAAAHAAAAACAAAAAAAAADAA
AAB1AAAAAAAEAAAAAABQAAAAdQAAAAAABAB7AAAAgAAAAJIAAACWAAAAmgAAAJ4AAACkAAAAqgAA
AHsAAACuAAAAkgAAAL8AAACaAAAAwwAAAKQAAADJAAAAUm9vdABWYWx1ZQBuYW1lAENoYXRUZXh0
RmFkZURlbGF5AG1pbgAxLjAAbWF4ADMwMC4wAHZhbHVlADguMABDaGF0VGV4dEZhZGVUaW1lADAu
MAAxMjAuMAAwLjMAUEsHCEIQyi/ZAAAA2QAAAFBLAwQUAAgIAABxjD5EAAAAAP//////////MQAA
AFRTVyBNb2RzLmxuay9GbGFzaC9JbXByb3ZlZFRleHRGYWRlL0NoYXJQcmVmcy54bWzvu788P3ht
bCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCIgc3RhbmRhbG9uZT0ieWVzIiA/Pgo8Um9v
dD4KICA8VmFsdWUgbmFtZT0iQ2hhdFRleHRGYWRlRGVsYXkiIG1pbj0iMS4wIiBtYXg9IjMwMC4w
IiB2YWx1ZT0iOC4wIiAvPgogIDxWYWx1ZSBuYW1lPSJDaGF0VGV4dEZhZGVUaW1lIiBtaW49IjAu
MCIgbWF4PSIxMjAuMCIgdmFsdWU9IjAuMyIgLz4KPC9Sb290PgoKUEsHCMn3R3HZAAAA2QAAAFBL
AwQUAAgIAAByjD5EAAAAAP//////////LgAAAFRTVyBNb2RzLmxuay9GbGFzaC9JbXByb3ZlZFRl
eHRGYWRlL3JlYWRtZS50eHRpbXByb3ZlZCB0ZXh0IGZhZGUNCg0KKlZlcnNpb24gMS4wKg0KDQot
IFRleHQgRmFkZSBEZWxheSBvcHRpb24gbWF4ZWQgdG8gMzAwc2VjICg1bWluKQ0KLSBUZXh0IEZh
ZGUgRGVsYXkgb3B0aW9uIG1pbmltdW0gdmFsdWUgc2V0IHRvIDFzZWMNCi0gVGV4dCBGYWRlIFRp
bWUgb3B0aW9uIG1heGVkIHRvIDEyMHNlYyAoMm1pbikNCg0KDQoqRGVzY3JpcHRpb24qIA0KDQpU
aGlzIG1vZCBhbGxvd3MgeW91IHRvIGV4dGVuZCB0aGUgY2hhdCAidGV4dCBmYWRlIGRlbGF5IiB0
aW1lIHRvIHVwIHRvIDVtaW5zIGZvciBhbGwgY2hhdHdpbmRvd3Mgd2l0aCAiVGltZW91dCBNZXNz
YWdlcyIgZW5hYmxlZCwgc28geW91IGNhbiBoYXZlIGEgc2hvcnQgYmlvIGJ1dCB3aWxsIHN0aWxs
IGJlIGFibGUgdG8gcmVhZCBsYXRlc3QgY2hhdG1lc3NhZ2VzLiBJdCBhbHNvIGFsbG93cyB0byBl
eHRlbmQgInRleHQgZmFkZSB0aW1lIiB0byB1cCB0byAybWlucy4gQm90aCBvcHRpb25zIGNhbiBi
ZSBmb3VuZCBpbiB5b3VyIGludGVyZmFjZSBtZW51IC0+ICJhZHZhbmNlZCIgdGFiLg0KDQoNCipI
b3cgdG8gaW5zdGFsbCoNCg0KLiB1bnBhY2sgSW1wcm92ZWRUZXh0RmFkZSBkaXJlY3RvcnkgaW50
byBcRGF0YVxHdWlcQ3VzdG9taXplZFxGbGFzaCBsb2NhdGVkIGluIHRoZSByb290IG9mIHlvdXIg
VFNXIGRpcmVjdG9yeSAobGlrZTogQzpcUHJvZ3JhbSBGaWxlcyAoeDg2KVxGdW5jb21cVGhlIFNl
Y3JldCBXb3JsZFxEYXRhXEd1aVxDdXN0b21pemVkXEZsYXNoXEltcHJvdmVkVGV4dEZhZGUpDQoN
Ci4gcmVzdGFydCB5b3VyIFRTVyBjbGllbnQNCg0KDQoqSG93IHRvIHVuaW5zdGFsbCoNCg0KLiBk
ZWxldGUgSW1wcm92ZWRUZXh0RmFkZSBkaXJlY3RvcnkgZnJvbSBcRGF0YVxHdWlcQ3VzdG9taXpl
ZFxGbGFzaCBsb2NhdGVkIGluIHRoZSByb290IG9mIHlvdXIgVFNXIGRpcmVjdG9yeQ0KDQouIHJl
c3RhcnQgeW91ciBUU1cgY2xpZW50DQoNCg0KLSBieSBEaWFsbG8gLVBLBwgLbl1b4AMAAOADAABQ
SwECFAAUAAgIAABxjD5EQhDKL9kAAADZAAAAMgAAAAAAAAAAACAAAAAAAAAAVFNXIE1vZHMubG5r
L0ZsYXNoL0ltcHJvdmVkVGV4dEZhZGUvQ2hhclByZWZzLmJ4bWxQSwECFAAUAAgIAABxjD5EyfdH
cdkAAADZAAAAMQAAAAAAAAAAACAAAAA5AQAAVFNXIE1vZHMubG5rL0ZsYXNoL0ltcHJvdmVkVGV4
dEZhZGUvQ2hhclByZWZzLnhtbFBLAQIUABQACAgAAHKMPkQLbl1b4AMAAOADAAAuAAAAAAAAAAAA
IAAAAHECAABUU1cgTW9kcy5sbmsvRmxhc2gvSW1wcm92ZWRUZXh0RmFkZS9yZWFkbWUudHh0UEsF
BgAAAAADAAMAGwEAAK0GAAAAAA==
Save as .b64 file and double click the file in Total Commander.

User avatar
karlchen
Power Member
Power Member
Posts: 4555
Joined: 2003-02-06, 22:23 UTC
Location: Germany

Post by *karlchen » 2014-01-31, 13:49 UTC

Hi, white.

Thanks for the file. :-)
Now I can reproduce the problem.
The symptoms to be seen on Total Commander 8.50 rc2 64-bit and Total Commander 8.50 rc2 32-bit :
  • When simply extracting the whole content including pathnames, the folder structure will be restored successfully.
  • But for each of the 3 files in the inner folder "ImprovedTextFade" I receive the error message, "Disk read error!" ("Fehler beim Lesen!").
  • The same error occurs when trying to view a file in the T.C. lister.
Also confirmed, 7-zip 9.20 will extract the archive including folder structure and files without any problem.

Cheers,
Karl
Linux Mint 19.2 32-bit xfce Desktop, Total Commander 9.22a 32-bit
Haß gleicht einer Krankheit, dem Miserere, wo man vorne herausgibt, was eigentlich hinten wegsollte. (Goethe)

User avatar
white
Power Member
Power Member
Posts: 2020
Joined: 2003-11-19, 08:16 UTC
Location: Netherlands

Post by *white » 2014-01-31, 14:22 UTC

At the bottom TC changes fields "version made by".

But it seems the problem has to do with the following values:

crc-32 4 bytes
compressed size 4 bytes
uncompressed size 4 bytes

crc values in problem zip are 00 00 00 00
size values in problem zip are FF FF FF FFF

When TC changes the zip these values are filled in.



Bit 3 of the general purpose bit flag seems to be set. CRC seems to be acording to spec. But sizes seem to be wrong.
http://www.pkware.com/documents/casestudies/APPNOTE.TXT wrote:The size of the file compressed (4.4.8 ) and uncompressed, (4.4.9) respectively. When a decryption header is present it will be placed in front of the file data and the value of the compressed file size will include the bytes of the decryption header. If bit 3 of the general purpose bit flag is set, these fields are set to zero in the local header and the correct values are put in the data descriptor and in the central directory. If an archive is in ZIP64 format and the value in this field is 0xFFFFFFFF, the size will be in the corresponding 8 byte ZIP64 extended information extra field.
Sizes in decryption header should be zero like crc-32. The value 0xFFFFFFFF seems to indicate ZIP64 format but the files does not seems to be in ZIP64 format.

After changing 0xFFFFFFFF into 0x00000000 in the decryption headers of the 3 files the zip file is fixed and can be processed by Total Commander.
Last edited by white on 2014-08-08, 15:01 UTC, edited 2 times in total.

User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 38145
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) » 2014-01-31, 16:15 UTC

Which program created this ZIP? Indeed it seems to violate some ZIP format standards.
Author of Total Commander
http://www.ghisler.com

User avatar
petermad
Power Member
Power Member
Posts: 8838
Joined: 2003-02-05, 20:24 UTC
Location: Valsted, Denmark
Contact:

Post by *petermad » 2014-01-31, 16:23 UTC

2ghisler(Author)
The test file is created by copy.com service so I don't know how exactly it is created.
License #524 (1994)
Danish Total Commander Translator
TC 9.5b3 32+64bit on Win XP 32bit, Win 7, 8.1 & 10 (1903) 64bit, 'Everything' 1.4.1.935 (x64)
TC 3.0b12 on Android 6.0
Get: Extended Total Commander Menus | PHSM-Calendar

User avatar
MVV
Power Member
Power Member
Posts: 8395
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV » 2014-01-31, 16:45 UTC

white wrote:crc values in problem zip are 00 00 00 00
size values in problem zip are FF FF FF FFF
For streaming packed/unpacked sizes and CRC may not be stored in file header but must be stored in data descriptors immediately after packed data, and in central directory at the end of file. On white's screenshot I can see data descriptors after packed data (they have optional magic 50 4B 07 08 and you can see correct CRC then). However according to standard, both sizes and CRC must be set to zero if data descriptors used:
4.3.9 Data descriptor:

crc-32 4 bytes
compressed size 4 bytes
uncompressed size 4 bytes

4.3.9.1 This descriptor MUST exist if bit 3 of the general
purpose bit flag is set (see below).
4.4.7 CRC-32: (4 bytes)
...
If bit 3 of the general purpose flag is set, this
field is set to zero in the local header and the correct
value is put in the data descriptor and in the central
directory.
...
4.4.8 compressed size: (4 bytes)
4.4.9 uncompressed size: (4 bytes)
...
If bit 3 of the general purpose bit flag is set,
these fields are set to zero in the local header and the
correct values are put in the data descriptor and
in the central directory.
...

User avatar
white
Power Member
Power Member
Posts: 2020
Joined: 2003-11-19, 08:16 UTC
Location: Netherlands

Post by *white » 2014-01-31, 16:56 UTC

ghisler(Author) wrote:Which program created this ZIP? Indeed it seems to violate some ZIP format standards.
Solf wrote:The test file is created by copy.com service so I don't know how exactly it is created.
Copy.com seems to be a file sharing website.

So according to spec the size values should be 0 in the local header if bit 3 of the general purpose flag is set. Why does Total Commander look there when bit 3 is set?

User avatar
MVV
Power Member
Power Member
Posts: 8395
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV » 2014-01-31, 17:45 UTC

white, bit 3 is set but sizes are not zero, they are 0xFFFFFFFF. Actually I don't understand why this site doesn't set file sizes in file headers, it doesn't pack files so sizes are known, only CRC is unknown.

I checked 7-Zip (9.20) sources, it detects descriptor only by bit 3.

Post Reply