Ensure that .bin files maintain executable bits in Windows bundles.
#8503
Conversation
| @@ -926,8 +940,13 @@ files.createTarGzStream = function (dirPath, options) { | |||
| // setting it in an 'entry' handler is the same strategy that npm | |||
| // does, so we do that here too. | |||
| if (entry.type === "Directory") { | |||
| entry.mode = (entry.mode || entry.props.mode) | 0o500; | |||
| entry.props.mode = entry.mode; | |||
| entry.props.mode = addExecBitWhenReadBitPresent(entry.props.mode); | |||
There was a problem hiding this comment.
Why is the | 0o500 no longer necessary? In other words, why not something like this:
entry.props.mode = addExecBitWhenReadBitPresent(
(entry.mode || entry.props.mode) | 0o500
);There was a problem hiding this comment.
First, I should point out that entry.mode is always undefined and never set, or used – maybe it was used in a previous version of fstream, but I can't find any (we use our own fork), and this behavior matches the published fstream behavior. The second parameter to the filter callback is actually props, so this would make sense in that scenario but this code doesn't do that, instead utilizing only the first argument which includes props as an attribute on entry.
For directories, I'd say that the | 0o500 (e.g. u+rx) was never necessary and that something less would have accomplished the goal. I'm happy to change that back, but my thinking was that it might be preferable to maintain some sense of permissions on Windows. Essentially, if a directory was encountered that had the readable bit missing, we shouldn't simply add that read bit and add the executable bit. Presumably there would be some reason that read permission (something Windows does understand) was not set. My train of thought was strongly influenced by that of the other PRs marked as closed and merged in the node-tar issue, for example, mapbox/node-pre-gyp@7a28f4b and microsoft/types-publisher@be20819#diff-db71419dab88a2797059646c6a31a328R42.
Windows has no concept of the executable bit so it is not applied by the `fstream` `Reader` when building the tarball which is used in both `meteor build` and `meteor deploy`. For Windows users, this causes important scripts (such as `node-pre-gyp`) to not be executable when the bundles are deployed to Unix platforms (such as Galaxy). To avoid giving every file executable bits, this applies an executable bit to the file only if it has read permission (something Windows _is_ aware of) and if it is in a location that Node bin links are typically placed, the `/node_modules/.bin/` directories.
benjamn
force-pushed
the
abernix/fix-windows-bin-link-perms
branch
from
647bd0d
to
ac55072
Compare
#Windows has no concept of the executable bit so it is not applied by the
fstreamReaderwhen building the tarball which is used in bothmeteor buildandmeteor deploy. For Windows users, this causes important scripts (such asnode-pre-gyp) to not be executable when the bundles are deployed to Unix platforms (such as Galaxy).To avoid giving every file executable bits, this applies an executable bit to the file only if it has read permission (something Windows is aware of) and if it is in a location that Node bin links are typically placed, the
/node_modules/.bin/directories.Additionally, to apply a slightly more conservative approach to the existing logic (which applied executable bits to all directories), this changes that logic to only apply the executable bit to readable directories, thus maintaining some degree of permissions control when building from a Windows system. This is in line with other projects linked in the comments and issues below, such as
node-pre-gypand other projects linked in thenode-tarissue.A symptom of this might be an error message such as: