Signature Error

[mindbits]

Hi,

I am getting

Error: invalid signature: 0x7853666a

on some files.

A sanity test of the zip file as well as the regular unzip shell command work fine without any issues.

Please advise

[herlon214]

The same to me... 👍

[zacronos]

I am also getting this. In my case, I am streaming zip files from an ftp. When I download the zip files manually via browser and unzip them myself, they work fine (using Keka on OSX, and also the command-line unzip utility).

I saw on node-unzip someone had a similar problem (streaming from HTTP, instead of FTP), and they said if they save the file to local filesystem first and then read it back in, the error would go away (EvanOxfeld#73). This workaround worked for me too -- though oddly, in the node-unzip issue, someone specifically claimed that bug was fixed in this fork

[xuanhun]

The same to me ....

[yinrong]

+1 please fix

[yinrong]

for my file, the invalid signature is 0x4b500003

[ramondeklein]

The problem with streaming ZIP files is that you cannot read the central directory header (located at the end of the file). Some ZIP files don't store the compressed/uncompressed sizes in the local file header, because the (un)compressed size isn't known upfront.

In that situation the size is set to 0 and a data descriptor is located at the end of the (compressed) data. But you don't know the data length, so you don't know where to look for it. Non-streaming unzippers just take a look at the central directory and get the size from there. Due to the streaming character of this module, this isn't possible.

The data descriptor starts with 0x08074b50, so this module tries to look for this DWORD in the (compressed) data. If it is found, then it assumes that it has found the end of the data. Although this might work, it's pretty error prone. There is no escaping method, so you don't know if you have matched data or the actual data descriptor.

This especially fails when storing ZIP files inside a ZIP file. You might hit the magic numbers of the embedded ZIP-file. You could do some additional checking to prevent this from happening. The compressed size should match the number of bytes you have actually read. If that doesn't match, then you probably got the incorrect data descriptor. You could also check CRCs. If it matches, then you're pretty sure that you got the correct data descriptor. If it doesn't, then the ZIP-file is corrupt anyway.

[ramondeklein]

The invalid signature byte is just file data, where it expected to find a signature. The data depends on the data that is stored.

[RayzRazko]

I got same error with large zip. It had lots of xml files. When I unzipped the content manually with other tools and zipped it again I got the same error. When I unzipped files and separated then into smaller chunks and zipped it again into multiple smaller zips - everything was okay.

[asaf050]

+1
Getting the same error

[thejoshwolfe]

can anyone provide an example zip file that reproduces this problem?

[asaf050]

@thejoshwolfe thanks :)
Holmatro Spreader Assembly_1.zip

[PhoenixUA]

Hey guys. Have the same error in exceljs lib loading xlsx-file.

Fatal Error: invalid signature: 0x5431cbd5
    at D:\Work\new_one\newone_api\node_modules\unzip2\lib\parse.js:63:13

[thejoshwolfe]

@PhoenixUA, would you mind providing the document (or a document) that reproduces the problem? I'm familiar with the zip file binary format, and I'm curious to know what exactly the issue is.

[PhoenixUA]

@thejoshwolfe yep, take that.
It reproduces on node v0.12.7 and v4.2.6

[thejoshwolfe]

@PhoenixUA, are you sure that document reproduces the issue? It seems to work find for me with this library (checked out at master) and node v4.2.6.

node-unzip-2$ node -e 'require("fs").createReadStream(".../Contracts Template_XYZ_16_6_1.xlsx").pipe(require("./").Extract({ path: ".../something" }));'

The above command completes without errors.

[oriregev]

I get the same error with a different file.
The following command fails on Node v6.10.1 with the attached to.zip file:

$ node -e 'require("fs").createReadStream("to.zip").pipe(require("unzip2").Extract({ path: "/tmp/test.out" }));'

Error: invalid signature: 0x4b500003
at /Users/.../node_modules/unzip2/lib/parse.js:63:13
at runCallback (timers.js:666:20)
at tryOnImmediate (timers.js:639:5)
at processImmediate [as _immediateCallback] (timers.js:611:5)

[thejoshwolfe]

the attached to.zip file

That zipfile uses general purpose bit 3, which is a feature that this node module doesn't seem to support. (It is a bit strange that a directory entry has a non-zero uncompressed size, but the central directory record is correct, so a spec compliant zip file reader should have no trouble with it.)

I recommend anyone getting this error should switch to my module yauzl for zipfile reading, or at least test to see if the examples/unzip.js utility can parse your zipfile. i especially made a point to follow the spec to avoid "signature errors" like the ones in this issue. (Note that yauzl has a different API than this module, and that's part of the reason why yauzl can handle more zipfiles than this module can.)

[oriregev]

@thejoshwolfe thanks for the clarification!

The zip file was created using Java's jar utility (part of the JDK).
The same problem happens with files created using Java's war utility, and I'm guessing that it would happen on other files created using Java's java.util.zip.ZipFile.

[akoptelov]

I experienced this problem until I added on('error') handler to the unzipped stream:

fs.createReadStream(f).pipe(unzip.Parse()).on('error', e => {...}).on('entry', e => ...);

See this comment. That works even without retrying unzipping.

[starrysec]

Getting the same error, but when you retry this file, it's OK!

[starrysec]

Can someone give me a suggestion?

[zacronos]

@penybai Try saving the file to the local filesystem, and then opening a new stream to read the saved file and unzipping that. This has worked for me, though some of the later comments imply it doesn't work for all situations.

[lorh2700]

I got the same Problem ... ( invalid signature: 0x8074b50 )
but I downgraded the unzipper to 0.10.4 and then it was fine