Error opening zip file

[maxsupermanhd]

10c-AllyToAlly-7e1e4457e81e95ffa5993e3f6ba484ac0ee2625729dfc85a5e48aeecaea1bb61.zip

[kuba--]

I'll take a look, maybe it's a backslash thingy. What tool did you use to compress it? Because zip format/standard requires / separators as entries names.

[sukhchainn]

corrupted zip file. Did he used zip library to compress it?

…

On Fri, 21 Jun, 2019, 7:15 PM Kuba Podgórski, ***@***.***> wrote: I'll take a look, maybe it's a *backslash* thingy. What tool did you use to compress it? Because zip format/standard requires / separators as entries names. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/kuba--/zip/issues/107?email_source=notifications&email_token=AHU4P664O3RWQKRDSIFTKUDP3TLPTA5CNFSM4H2ROII2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYIQFNY#issuecomment-504431287>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHU4P6YOJO67EJ4XBESU3QLP3TLPTANCNFSM4H2ROIIQ> .

[maxsupermanhd]

Its Warzone2100 map format.
Backslashes works with other zips.
File not corrupted and had .wz extension and renamed to .zip for github.
I think bc of 3.55 compression raito.

Edit: unzip and other zip-reading programs works good.

[maxsupermanhd]

For some reason look into my project. May be im doing something wrong...
https://github.com/maxsupermanhd/WMT

[kuba--]

It fails in line: https://github.com/kuba--/zip/blob/master/src/miniz.h#L4591
for following if:

if (((!MZ_READ_LE32(p + MZ_ZIP_CDH_METHOD_OFS)) &&
           (decomp_size != comp_size)) ||
          (decomp_size && !comp_size) || (decomp_size == 0xFFFFFFFF) ||
          (comp_size == 0xFFFFFFFF))
        return MZ_FALSE;

because decomp_size and comp_size are equal 0xFFFFFFFF

[kuba--]

and if you take a look into central directory of the zip file you can see that some entries contain 64-bit sizes, e.g.:

Central directory entry #4:
---------------------------

  multiplay\maps\10c-AllyToAlly\

  offset of local header from start of archive:   408
                                                  (0000000000000198h) bytes
  file system or operating system of origin:      MS-DOS, OS/2 or NT FAT
  version of encoding software:                   4.5
  minimum file system compatibility required:     MS-DOS, OS/2 or NT FAT
  minimum software version required to extract:   4.5
  compression method:                             deflated
  compression sub-type (deflation):               normal
  file security status:                           not encrypted
  extended local header:                          no
  file last modified on (DOS date/time):          2011 Feb 24 15:00:20
  32-bit CRC value (hex):                         00000000
  compressed size:                                0 bytes
  uncompressed size:                              0 bytes
  length of filename:                             30 characters
  length of extra field:                          20 bytes
  length of file comment:                         0 characters
  disk number on which file begins:               disk 1
  apparent file type:                             binary
  non-MSDOS external file attributes:             000000 hex
  MS-DOS file attributes (10 hex):                dir 

  The central-directory extra field contains:
  - A subfield with ID 0x0001 (PKWARE 64-bit sizes) and 16 data bytes:
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00.

[maxsupermanhd]

So how can i fix/open this thing without zip modification?

[kuba--]

I'll take a look if I can quickly add 64bit support by merging/upgrading parts of miniz thirdparty.
...or maybe somehow I can ignore those 64bit subfields.

[maxsupermanhd]

This will be very good if it will work

[maxsupermanhd]

Can we just ignore this fields or bypass this if somehow? Of course we can but Will this be safe for reading or it will corrupt something?

[kuba--]

@maxsupermanhd - I believe miniz already fixed the problem for 64bit fields. I just need to update our miniz fork. But because it required a little bit hacking I have to do it carefully and not to break anything.

[maxsupermanhd]

So updating miniz header can help?
And its not problem of this library?

[kuba--]

It not as easy as replacing a header file - miniz changed a lot over time (split into multiple files etc.). Moreover in this library miniz was a little bit hacked to be able to achieve easy to use zip interface.

[maxsupermanhd]

Sow how can i solve this? Just gui pull?

[kuba--]

I've started porting slowly (in my spare time).

[kuba--]

@maxsupermanhd - I have a PR (https://github.com/kuba--/zip/pull/108) for branch fix-107/x64. It should fix your problem - could you take a look?
The build so far fails on windows (I'll have to fix it with MSVC), but so far you can test it on linux/osx.

[kuba--]

btw. windows build fixed.

[kuba--]

@maxsupermanhd - ping

[maxsupermanhd]

Yey! Will test as soon as possible.

[maxsupermanhd]

On first look seems to be working. Still need to do some more tests but this zip file now working.

[kuba--]

@maxsupermanhd - shall I merge #108 into the master? Does it work for you?
If yes, I can release a new version.