Extension zipped using Mac Finder doesn't install on Windows

[njx]

1. On Windows, attempt to install the extension from this ZIP:
   https://dl.dropboxusercontent.com/s/sj7d7te2b3t58kj/brackets-bower-dist-0.1.2.zip?dl=1&token_hash=AAGdCHqeS_UObLuNCAH8C0Z40mc0MZ6Vi7C0ZTSnP6gMVQ

Result: Error installing extension. The extension installs fine on Mac. This ZIP file was created via Finder, so it has the __MACOSX folder in it, but it doesn't seem like that should cause a problem since we explicitly ignore that folder, I believe.

[njx]

This seems similar to #6059, but in that case the installation failed on Mac too (and I think was fixed by an update to the node unzip library we were using).

[njx]

FWIW, I can't reproduce this on my Win 7 machine, but both @busykai and @Den-dp reported it.

[njx]

Actually...the original errors were reported as being during the update workflow. Perhaps it only reproduces when updating. That's harder to create repro steps for though...would probably have to hack Brackets (use a dummy registry file) in order to try to repro it.

[busykai]

Actually, I was able to reproduce it trying to install the above mentioned extension as well as on update. I'm on Win 7 x32_64.

[busykai]

I've installed ZipViewerTool and it shows some issues with the zip file packaged using Finder's Compress, while command-line based zip shows the archive as clean. Tool's color pattern is ugly, but the yellow means "file recovery is possible". Apparently, whatever these Mac deviations from zip format are, they are subtle -- I was able to unzip the problematic version with all zip utilities I have, except node's unzip. Perhaps, it makes sense to come up with a simple test using node's unzip. It could also be used to gateway zip formats it couldn't understand.


P.S. WinZip's diagnostics does not report anything suspicious, except, perhaps, there's a minimal unzip version (2.0) which is needed to unzip -- need to check if it's supported by npm's unzip.

[peterflynn]

Have we looked to see whether there are any bugs / known issues about this in the Node unzip library's repo? Seems like the most ideal way to address this would be getting a fix from upstream, so if they're not aware of this issue we may want to file it with them...

[busykai]

There are multiple issues related to variety of ways a zip entry could be formatted, particularly this one: EvanOxfeld/node-unzip#10. When I have a minimized test case, I'll submit an issue. I wanted to back my assumption with some code first (and it's holiday season anyways :).

[busykai]

Confirmed. Simple unzip code:

var fs = require('fs'),
    unzip = require('unzip');

fs
    .createReadStream('c:\\Users\\aikinzha\\Downloads\\brackets-bower-0.1.2.zip')
    .pipe(unzip.Extract({ path: 'c:\\temp\\' }));

throws the following:

events.js:72
        throw er; // Unhandled 'error' event
              ^
Error: invalid distance too far back
    at Zlib._binding.onerror (zlib.js:295:17)

Quick search showed that, for example, bower switched (bower/bower#937) from unzip to bower/decompress-zip due to similar issues that were not being attended by unzip maintainers. unzip repository at a closer look is quite stale. Perhaps, we should consider switching to decompress-zip as well? I can look up some alternatives to decompress-zip and prepare a PR for the best option.

P.S. decompress-zip seems to be attractive as it will most likely have the same lifespan as bower itself.

[njx]

I vaguely remember that @dangoor might have been looking into alternatives to node-unzip as well (and might even have mentioned decompress-zip). This seems like a good reason.

I wonder, though, why this only reproduces on some machines but not others...

[dangoor]

We don't use node-unzip any more. We switched to decompress-zip when we upgraded to Node 0.10

[njx]

Medium priority to @dangoor to investigate. I could imagine this being a low if we just document the workaround that you should zip from the command line rather than Finder, but it scares me a bit.

[busykai]

heh, this is embarrassing... why i assumed unzip in the first place? anyway, standalone test using decompress-zip with the above mentioned file works. will see what's the problem when installing.

[busykai]

Ok. This is a dup of #5897 resolved by #5919. @dangoor , please close.

The reason it was not failing for @njx is the Brackets version. Apparently, command line version of zip does not archive symlinks as such by default, but archives a copy instead. Finder's Compress creates symlinks which decompress-zip cannot process. Here's a difference between two versions packaged using command-line (first) and Finder (second), note the size of .bin/bower in both cases:

<kai@prodigy(pts/2).39 ~/tmp>
--> unzip -l brackets-bower-0.1.3.zip | grep bin/bower
     3380  11-19-2013 23:23   brackets-bower-dist/node/node_modules/.bin/bower
     3380  11-19-2013 23:23   brackets-bower-dist/node/node_modules/bower/bin/bower
<kai@prodigy(pts/2).40 ~/tmp>
--> unzip -l brackets-bower-0.1.2.zip | grep bin/bower
       18  11-19-2013 18:23   brackets-bower-dist/node/node_modules/.bin/bower
     3380  11-19-2013 23:23   brackets-bower-dist/node/node_modules/bower/bin/bower

The fix skips creation of symlinks which is OK as long as all these dependencies are installed locally.

[dangoor]

Thanks for confirming that this is a dupe, @busykai. I'll close this.

I wasn't completely sure about the skipping of symlinks when I merged that in, but it seemed to be only for the script files when npm installs, so it seemed safe enough.