thejoshwolfe / yazl

yet another zip library for node
MIT License
322 stars 44 forks source link

Zip file created by yazl not openable in Windows Explorer #53

Open Matt4880 opened 5 years ago

Matt4880 commented 5 years ago

I'm using Yazl 2.5.1 as the final step of a Node-based build process to package my application. We occasionally find that the files produced will not open in native Windows Explorer (usually Win10) with Windows complaining that 'the compressed (zipped) folder '***' is invalid'

I am, however, able to open the archive using 7zip (v16.02)

The snippet of code I'm using to zip is

    var yazl = require("yazl");
    var zipfile = new yazl.ZipFile();
    zipfile.addFile(outputFilePath, setupFilename);
    zipfile.outputStream.pipe(fs.createWriteStream(outputFilePath.replace(/\.exe$/,'.zip')));

where variables outputFilePath, setupFilename have been already defined.

fs is using fs-extra

thejoshwolfe commented 5 years ago

Corrupt zipfile bugs usually happen when you don't wait for the operation to finish before trying to read it. I don't know if that's what's happening here; I don't see anything wrong with the code you posted.

Is it possible to share a zipfile that demonstrates the incompatibility? I might be able to spot something wrong with it by examining the binary file.

I've tested unzipping yazl-created zipfiles with the Windows 7 compressed folder utility before, so it's supposed to work. (The Mac Archive Utility has known issues, by contrast.)

Matt4880 commented 5 years ago

Any way I can send you a link? It's around 25Mb, so going via Google Drive prob works best

thejoshwolfe commented 5 years ago

thejoshwolfe@gmail.com

thejoshwolfe commented 5 years ago

It does appear that the file is prematurely truncated. There's no Central Directory, which is supposed to come at the end of the file. I'm not sure what 7-Zip is doing to recover from that kind of corruption, but the standard linux command line program unzip is also not able to read it.

The stream created by fs.createWriteStream(outputFilePath.replace(/\.exe$/,'.zip')) will emit a 'close' event when the file has been completed. It's necessary to wait for that event on Windows before trying to do anything with it (and on posix, you really only need to wait for the 'finish' event, but the 'close' event is ok there too.) This is not yazl-specific; this is just how streams work in Node.

Matt4880 commented 5 years ago

OK thanks. Had suspected it may be something like that, but was led astray when 7-zip could open it.

ricky11 commented 4 years ago

did you fix this matt