Zip file permissions obtained from stat incorrect/inconsistent on Windows

[Tim-B]

I've been investigating an issue on one of my own projects reported by Windows users, which I've been testing in a Windows VM and I think I've narrowed down the issue.

If you use .bulk() it obtains file permissions via stat, but on Windows these values seem incorrect.

Here's the output of a very simple example zip run through zipinfo:

When generated from Ubuntu:

Archive:  output_ubuntu.zip
Zip file size: 376 bytes, number of entries: 3
drwxrwxr-x  4.5 unx        0 b- stor 15-May-24 00:46 folder1/
drwxrwxr-x  4.5 unx        0 b- stor 15-May-24 00:47 folder1/folder2/
-rw-rw-r--  4.5 unx       12 bl defN 15-May-24 00:47 folder1/folder2/test.txt
3 files, 12 bytes uncompressed, 14 bytes compressed:  -16.7%

When generated from Windows:

Archive:  output_windows.zip
Zip file size: 376 bytes, number of entries: 3
drw-rw-rw-  4.5 unx        0 b- stor 15-May-24 00:53 folder1/
drw-rw-rw-  4.5 unx        0 b- stor 15-May-24 00:53 folder1/folder2/
-rw-rw-rw-  4.5 unx       12 bl defN 15-May-24 00:47 folder1/folder2/test.txt
3 files, 12 bytes uncompressed, 14 bytes compressed:  -16.7%

Note that the directories on Windows don't have the execute bit set, which causes problems on some systems which extract them.

I did some further debugging and printed some debugging information around the stat code and noticed the following:

For a directory:

data.stats.mode = 16822
data.mode = 438 after line 196

Which is what you'd expect seeing as 16822 & 0777 is 438 which is 110110110 in binary, ie. 666 in octal.

Here's some files to help you replicate the issue:

• Ubuntu example zip
• Windows example zip
• Example script to generate zip

[ctalkington]

thanks for the research on this. will do some testing this weekend.

[paulrutter]

Any progress on this issue?
As a temporary workaround on Windows, i've set the mode to 0777 always.

Line 200:

data.mode = 0777;

This way, directories get all rights (notice that 777 is unsafe, but you can change it to any number you want).

[lotterfriends]

Thanks for the tip as hotfix this works for me: lotterfriends@a250395

[Tim-B]

You can find another possible workaround here: https://github.com/Tim-B/grunt-aws-lambda/blob/master/tasks/lambda_package.js#L77

It doesn't require you to maintain a separate copy of node-archiver that way, although you'd probably still want to lock your version.

[ctalkington]

is there a reason that something like: 493 (0755) wouldnt work here.

it seems like a safer default.

[ctalkington]

ive been going back and forth on how to best handle this which on top of a busy schedule delayed any fix in 0.15.0. ive put in a temporary fix in 0.15.1 which will force mode to 0755 (saner than 0777 imho) for directory modes that are provided by stat.

this was after spending an hour trying to come up with a bitwise to enforce minimum of 0755 but its easier said than done compared to 0777. if someone comes up with a reliable bitwise statement, im happy to try it out but otherwise i think this solution will address the issue and prevent the need for hacking archiver for an oddity in cross platform stat.

[lotterfriends]

Thanks for your fix and feedback. I'm glad to use your version again :)