Problem with OSX's unzip

[sindresorhus]

Problem with OSX's unzip

[dduponchel]

The underlying library, JSZip, creates zip files without any metadata (like the UNIX rights). After extraction, you will likely get files with 644 permissions.

[adam-lynch]

@dduponchel hmm yeah, so I guess this is unexpected behaviour. Someone correct me if I'm wrong.

By the way, when I'm extracting using Finder, Finder must be somehow making up for the lack of metadata, right? Like, it must be finding and marking executables within (or even the entire contents) as 777 or something. Not really making a point here, just wondering.

[dduponchel]

The field "made by" is set to "DOS" : the archive manager knows that there won't be any useful metadata so it usually creates files with the default rights (I tested with unzip on linux). I never played with Finder, it may have a different behavior (like checking if the file is a .app).
I created a feature request on JSZip side, see Stuk/jszip#194.

[adam-lynch]

Thanks @dduponchel 😄

[adam-lynch]

I don't understand why this is closed. It's not fixed or anything.

[sindresorhus]

I think I closed the wrong issue. Sorry.

[adam-lynch]

No prob :)

On Tue, 13 Jan 2015 18:00 Sindre Sorhus [email protected] wrote:

I think I closed the wrong issue. Sorry.

—
Reply to this email directly or view it on GitHub
#38 (comment)
.

[kevva]

@adam-lynch, could you try my fork https://github.com/kevva/gulp-zip/tree/yazl?

[brian-mann]

@adam-lynch I'm getting the exact same problem, and I can tell you're using this on node-webkit 😉

Swapping out to the yazl fork does indeed seem to fix the issue.

[adam-lynch]

@kevva sorry, didn't see your reply 'til now. I might be able to later.

[brian-mann]

@adam-lynch @kevva Actually nevermind, this fork is blowing up when I try to zip up my app.

buffer.js:176
        this.length = +subject > 0 ? Math.ceil(subject) : 0;
                                          ^
RangeError: Maximum call stack size exceeded

[adam-lynch]

Looks like it's sorted in jszip; Stuk/jszip#200

[brian-mann]

Nope. Still cannot get zipping to work even on that commit.

It zips just fine, and unzips just fine (from the terminal) but after unzipping and trying to open my app it gives me:

LSOpenURLsWithRole() failed with error -10810 for the file

[dduponchel]

@brian-mann after unzipping, what permissions do you have on the file ?
JSZip will need two things in your case : unixPermissions:{executable:true} when adding the file and platform:"UNIX" when generating the zip file.

[brian-mann]

I spent about 6 hours today working with every zip library for node. The only one that has worked was using https://github.com/thejoshwolfe/yazl

No permission issues, zipping issues, or unzipping issues. Using it directly what the only way I could get anything to work.

[dduponchel]

I can't test it (I don't have OSX) but a search on your error indicates that a chmod a+x of the file before zipping it could solve the issue (so an issue with the file mode inside the zip), hence my question :)
JSZip generates now a 755 file inside the zip when asked to : from what I understand it should be enough. Yazl re-uses the exising file mode : what do you have for the app file ?
Using JSZip, could you confirm that, when extracted, the app file mode is 755 ? And check if your test still fail.

[dduponchel]

I just checked with a trainee with a mac at work, the inside of its apps have a umask of 002 : the files are 664, the folders are 775 (some even in 777). I'll do like yazl and reuse directly the mode.

[dduponchel]

I pushed updated code for JSZip and gulp-zip on git branches :

• jszip on https://github.com/dduponchel/jszip/tree/wip_unix_mode
• gulp-zip on https://github.com/dduponchel/gulp-zip/tree/wip_unix_mode (which depends on the jszip branch)

This version should generate 775 folders and keep the original file mode. Could you check if that fix your issue ?

[adam-lynch]

Confirmed that it's fixed as of 3.0.1 😄