Recent changes to support-requests

#20 After decompression ...

2025-07-18T02:54:53.391000Z

On Win 10 ( 32 bit ) computer ...

Ok.

Use WinRAR to decompress ...

Not our program. Not our problem.
Still more questions than answers. For example:

"After decompression" of what? How was your (invisible) zip
archive created?

How do you know that there are ".exe" files in your original folder?

How do you know that there are ".exe" files in your archive?

Even if you were using our software, you would still need to
provide some basic information, and you have not done that.

#20 After decompression ...

2025-07-17T12:51:20.854000Z

WinRAR is off-topic for this list.

This forum is only for the Info-ZIP zip & unzip programs. It doesn't cover WinRAR

Try uncompressing with unzip or 7z. If it fails with unzip, ask here again.

#20 After decompression ...

2025-07-17T05:06:21.245000Z

On Win 10 ( 32 bit ) computer ...

Use WinRAR to decompress ...

#20 After decompression ...

2025-07-12T03:19:23.112000Z

> After decompression ...
> No .exe file was found on the decompressed folder ...

   Before anyone can help you, you will need to provide some basic
information about your environment(s), what you did, and what happened
when you did it.

   Hardware?  Software?  OS/version?

      zip -v

      unzip -v

   Actual commands?  Actual results?  Copy+paste is your friend.

   "After decompression" of _what_?  How was your (invisible) zip
archive created?

   How do you know that there are ".exe" files in your original folder?
   How do you know that there are ".exe" files in your archive?

   Imagine that _you_ knew something, and someone asked _you_ this
question.  What would _you_ want to know?

After decompression ...

2025-07-11T22:44:51.562000Z

Downloaded from here ( https://sourceforge.net/projects/infozip/ ) ...

.........................

After decompression ...

No .exe file was found on the decompressed folder ...

#19 Zip 2.0?

2024-06-06T10:29:09.690000Z

Comparing the first zipinfo listing with the most recent, the differences are the following fields

offset of local header from start of archive
minimum software version required to extract
32-bit CRC value (hex)
compressed size
uncompressed size

All but the "minimum software version required to extract" you would expect to change if you've modified the file.

The " minimum software version required to extract" has changed from 2.0 to 1.0, so I assume that is the one you are concerned with.

classes5.dex is not encrypted, is not a directory and does not use deflate compression. That means the 1.0 version is fine.

A root-cause is down to the code that wrote the original zip file and set the version to 2.0 incorrectly.

Regardless, the change from 2.0 to 1,0 doesn't make any difference to the standard zip/unzip utilities.

Is there something special in your workflow that needs this field to match? Can you explain more why it matters?

#19 Zip 2.0?

2024-06-06T09:59:37.874000Z

I guess it has become an episode of "how do I recreate this original file" more than anything being "wrong" per se. Let me illustrate it better.

Here's the zipinfo -v of the classes.dex files inside a framework.jar - they are created with this "metadata"

Central directory entry #53:
---------------------------

  classes5.dex

  offset of local header from start of archive:   39838572
                                                  (00000000025FE36Ch) bytes
  file system or operating system of origin:      Unix
  version of encoding software:                   2.0
  minimum file system compatibility required:     MS-DOS, OS/2 or NT FAT
  minimum software version required to extract:   2.0
  compression method:                             none (stored)
  file security status:                           not encrypted
  extended local header:                          no
  file last modified on (DOS date/time):          2008 Jan 1 00:00:00
  32-bit CRC value (hex):                         8cc88e52
  compressed size:                                8412828 bytes
  uncompressed size:                              8412828 bytes
  length of filename:                             12 characters
  length of extra field:                          0 bytes
  length of file comment:                         0 characters
  disk number on which file begins:               disk 1
  apparent file type:                             binary
  Unix file attributes (100644 octal):            -rw-r--r--
  MS-DOS file attributes (00 hex):                none

  There is no file comment.

When I mod a classes.dex file and re-add it with latest Zip bin it comes out like this ( zip -0 -X framework.jar -v classes5.dex)

  classes5.dex

  offset of local header from start of archive:   40137562
                                                  (000000000264735Ah) bytes
  file system or operating system of origin:      Unix
  version of encoding software:                   3.0
  minimum file system compatibility required:     MS-DOS, OS/2 or NT FAT
  minimum software version required to extract:   1.0
  compression method:                             none (stored)
  file security status:                           not encrypted
  extended local header:                          no
  file last modified on (DOS date/time):          2008 Jan 1 00:00:00
  32-bit CRC value (hex):                         7499adcd
  compressed size:                                8703648 bytes
  uncompressed size:                              8703648 bytes
  length of filename:                             12 characters
  length of extra field:                          0 bytes
  length of file comment:                         0 characters
  disk number on which file begins:               disk 1
  apparent file type:                             binary
  Unix file attributes (100644 octal):            -rw-r--r--
  MS-DOS file attributes (00 hex):                none

  There is no file comment.

When using the 2.0 version you linked it's definitely closer, but he min software version is also off lol - what is going on here?

Central directory entry #53:
---------------------------

  classes5.dex

  offset of local header from start of archive:   40137562
                                                  (000000000264735Ah) bytes
  file system or operating system of origin:      Unix
  version of encoding software:                   2.0
  minimum file system compatibility required:     MS-DOS, OS/2 or NT FAT
  minimum software version required to extract:   1.0
  compression method:                             none (stored)
  file security status:                           not encrypted
  extended local header:                          no
  file last modified on (DOS date/time):          2008 Jan 1 00:00:00
  32-bit CRC value (hex):                         7499adcd
  compressed size:                                8703648 bytes
  uncompressed size:                              8703648 bytes
  length of filename:                             12 characters
  length of extra field:                          0 bytes
  length of file comment:                         0 characters
  disk number on which file begins:               disk 1
  apparent file type:                             binary
  Unix file attributes (100644 octal):            -rw-r--r--
  MS-DOS file attributes (00 hex):                none

  There is no file comment.

#19 Zip 2.0?

2024-06-06T03:51:39.435000Z

[...] which looks to me like a bug, [...]

CHANGES says that this was fixed in Zip version 3.1d03. Current
development code (3.1e23) works correctly.

#19 Zip 2.0?

2024-06-05T22:49:00.412000Z

[...] requiring a minimum version of Zip 2.0 to extract ... however, I
cannot seem to find this version existing anywhere, [...]

So what? Which part of "minimum" is unclear to you?

According to the APPNOTE:
https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT

Version Needed To Extract = 2.0 for an archive member means that one
of the following features was used:
File is a folder (directory)
File is compressed using Deflate compression
File is encrypted using traditional PKWARE encryption

I just ran a quick test with Zip 3.0 which seemed to leave that value
at 1.0 (the default) for a directory, which looks to me like a bug, but
I doubt that it would cause any practical effects. A text file which
was stored got 1.0, and a text file which was deflated got 2.0 (both as
expected).

When I attempt to match this files characteristics 1:1 [...]

Why do you want to do that? Is there some actual problem which you
are trying to solve?

Which program was used to make the archive in question? I doubt very
much that it was Zip 2.0.

[...] where can I find the exact version that will recreate 2.0 for
both of these fields?

I wouldn't do it, but if you have time to waste, there is a Zip 2.0
kit (source plus VMS (VAX?) binaries) here:

  http://antinode.info/ftp/info-zip/zip20.zip

but, as those source files are more than thirty years old (with all the
bugs that that implies), I don't know if you'll be able to make it work
on your (unspecified) system. I also don't know if it "will recreate
2.0 for both of these fields".

You could also modify the Zip source code to put any data you want
into an archive, but whether that would make any sense is a different
question.

#19 Zip 2.0?

2024-06-05T19:44:13.919000Z

The term "version needed to extract" refers to the version of the zip specification and not the version of any zip/unzip implementation. See section 4.4.3.1 of APPNOTE.txt at https://pkwaredownloads.blob.core.windows.net/pem/APPNOTE.txt for the details.

That then means you just need an unzip implementation that supports version 2 or better of the APPNOTE.txt specification.

I'm not aware of any unzip implementation that doesn't support version 2 of the spec (which was written in the early 1990s)

If you are having trouble reading your zip file, can you share a link to it? if it isn't too big could you attach it to a post here?