-
Notifications
You must be signed in to change notification settings - Fork 29.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lib,test: Use long paths when loading native addons #2965
lib,test: Use long paths when loading native addons #2965
Conversation
@@ -466,7 +466,9 @@ Module._extensions['.json'] = function(module, filename) { | |||
|
|||
|
|||
//Native extension for .node | |||
Module._extensions['.node'] = process.dlopen; | |||
Module._extensions['.node'] = function (module, filename) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
style nit: no space after function
keyword
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed thanks.
I wanted to add that I tried making a test for this, but that would entail actually loading a native addon (I think). And I couldn't find an example of another test doing that so I'm not sure how to effectively make a test for this. I'm open for input on how best to achieve that. |
I don't see a problem with that. It should be cc @bnoordhuis? |
@Fishrock123 Great, thanks. Looking now. |
@Fishrock123 I apologize for the delay but based on your feedback I added a unit test that successfully loads the addon from a long path. |
I tried running eslint like this:
But I get a ton of existing errors. The CONTRIBUTING.md documentation just says:
I'm not totally sure that I'm doing it right. |
For linting just run
|
066501e
to
04e3ff7
Compare
@Fishrock123 Again, thank you for your patience and your help :) I ran the tests and the linter successfully. I rebased my commits into a single commit with a descriptive comment and recently rebased |
|
||
// Attempt to load at long path destination | ||
var addon = require(addonDestinationPath); | ||
assert(addon != null); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you assert.equal(addon.hello(), 'world');
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@justinmchase Are you intentionally comparing against both null
and undefined
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@thefourtheye I believe I just copied that line from another test doing something similar. However, I think its most accurate to say that addon
should be neither null
or undefined
. So yes it is intentional.
Also, the error case before this PR actually throws an error instead of returning null
or undefined
. So it's mostly just a sanity check. Same with the following line which actually calls the addon.hello()
function, another sanity check.
LGTM but someone from @nodejs/platform-windows should sign off on this, I'm not sure to what extent LoadLibrary() supports UNC paths. |
Also, you might want to make sure that the commit is reflected in your GitHub profile. https://help.github.com/articles/setting-your-email-in-git/ |
It should work, although a comment on the doc page suggests that it doesn't for 32-bit builds. Did you test this? |
04e3ff7
to
450d406
Compare
When using require to load a native addon the path must be converted into a long path, otherwise the addon will fail to be loaded on windows if the path is longer than 260 characters.
@piscisaureus I didn't, I only tested on x64. I don't know if I trust that comment but I will make a VM and try it there, it could take a little while. @thefourtheye I think the machine I happened to make this branch on hadn't been configured right but commit itself should have the right email and name now. Sorry for that. |
LGTM, thanks for this it was a painful issue in the past too :D |
/cc @nodejs/build - I think our Windows CI bots only test 64 bits builds now? |
@bnoordhuis : correct (even though I would like to fix that). |
@bnoordhuis @piscisaureus I built an x86 win7 vm and tested it there, confirmed it works on x86 as well. |
I added a correcting comment to msdn to help prevent confusion in the future: |
CI seems happy. |
When using require to load a native addon the path must be converted into a long path, otherwise the addon will fail to be loaded on windows if the path is longer than 260 characters. PR-URL: #2965 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Benjamin Gruenbaum <inglor@gmail.com>
Landed in 8593b3e, thanks Justin. I had to touch up the first line of the commit log to make it fit in <= 50 columns, hope you don't mind. |
When using require to load a native addon the path must be converted into a long path, otherwise the addon will fail to be loaded on windows if the path is longer than 260 characters. PR-URL: #2965 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Benjamin Gruenbaum <inglor@gmail.com>
Currently, it's possible for a native addon on windows to throw an exception during module loading if it's path is too long.
This change resolves the issue by converting the path to the addon to a long path before calling
process.dlopen
.Fixes #2964