lib,test: Use long paths when loading native addons by justinmchase · Pull Request #2965 · nodejs/node

justinmchase · 2015-09-19T22:18:41Z

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

targos · 2015-09-19T22:42:33Z

style nit: no space after function keyword

Fixed thanks.

justinmchase · 2015-09-19T23:29:33Z

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.

Fishrock123 · 2015-09-20T00:32:59Z

but that would entail actually loading a native addon

I don't see a problem with that. It should be test/addons/ though. An example can be found here, I think: https://github.com/nodejs/node/pull/2830/files

cc @bnoordhuis?

justinmchase · 2015-09-20T02:13:49Z

@Fishrock123 Great, thanks. Looking now.

justinmchase · 2015-09-24T01:54:59Z

@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.

justinmchase · 2015-09-24T02:04:56Z

I tried running eslint like this:

node tools/eslint/bin/eslint.js lib/module.js --rulesdir tools/eslint-rules --quiet

But I get a ton of existing errors. The CONTRIBUTING.md documentation just says:

Make sure the linter is happy and that all tests pass.

I'm not totally sure that I'm doing it right.

Fishrock123 · 2015-09-24T02:48:56Z

For linting just run make jslint :)

On Sep 23, 2015, at 7:05 PM, Justin Chase notifications@github.com wrote:
I tried running eslint like this:
node tools/eslint/bin/eslint.js lib/module.js --rulesdir tools/eslint-rules --quiet
But I get a ton of existing errors. The CONTRIBUTING.md documentation just says:
Make sure the linter is happy and that all tests pass.
I'm not totally sure that I'm doing it right.
—
Reply to this email directly or view it on GitHub.

justinmchase · 2015-09-24T04:12:06Z

@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 upstream/master into my branch. I believe that this is ready for merging.

bnoordhuis · 2015-09-30T11:28:32Z

Can you assert.equal(addon.hello(), 'world'); here?

@justinmchase Are you intentionally comparing against both null and undefined here?

@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.

bnoordhuis · 2015-09-30T11:29:56Z

LGTM but someone from @nodejs/platform-windows should sign off on this, I'm not sure to what extent LoadLibrary() supports UNC paths.

CI: https://ci.nodejs.org/job/node-test-pull-request/401/

thefourtheye · 2015-09-30T12:39:24Z

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/

piscisaureus · 2015-09-30T13:58:26Z

LGTM but someone from @nodejs/platform-windows should sign off on this, I'm not sure to what extent LoadLibrary() supports UNC paths.

It should work, although a comment on the doc page suggests that it doesn't for 32-bit builds. Did you test this?

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.

justinmchase · 2015-09-30T14:24:39Z

@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.

benjamingr · 2015-09-30T14:48:23Z

LGTM, thanks for this it was a painful issue in the past too :D

bnoordhuis · 2015-10-01T19:36:41Z

/cc @nodejs/build - I think our Windows CI bots only test 64 bits builds now?

orangemocha · 2015-10-01T19:44:58Z

@bnoordhuis : correct (even though I would like to fix that).

justinmchase · 2015-10-01T20:54:35Z

@bnoordhuis @piscisaureus I built an x86 win7 vm and tested it there, confirmed it works on x86 as well.

justinmchase · 2015-10-02T15:22:55Z

I added a correcting comment to msdn to help prevent confusion in the future:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms684175(v=vs.85).aspx#12

bnoordhuis · 2015-10-03T21:34:21Z

CI: https://ci.nodejs.org/job/node-test-pull-request/414/

Fishrock123 · 2015-10-05T19:31:29Z

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>

bnoordhuis · 2015-10-05T20:10:34Z

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>

targos reviewed Sep 19, 2015
View reviewed changes

targos added module Issues and PRs related to the module subsystem. windows Issues and PRs related to the Windows platform. labels Sep 19, 2015

justinmchase force-pushed the use-long-path-to-load-addons branch 2 times, most recently from 066501e to 04e3ff7Compare September 24, 2015 04:07

justinmchase changed the title ~~Use long paths when loading native addons~~lib,test: Use long paths when loading native addonsSep 25, 2015

bnoordhuis reviewed Sep 30, 2015
View reviewed changes

justinmchase force-pushed the use-long-path-to-load-addons branch from 04e3ff7 to 450d406Compare September 30, 2015 14:16

lib,test: Use long paths when loading native addons (windows only)
450d406
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.

bnoordhuis closed this Oct 5, 2015

jasnell mentioned this pull request Oct 8, 2015
Preparing v4.x for LTS #3252
Closed
29 tasks

jasnell added the lts-landed-on-v4.x label Oct 8, 2015

jasnell mentioned this pull request Oct 8, 2015
Release proposal: v4.2.0 'Argon' (LTS) #3258
Closed

seishun mentioned this pull request Oct 15, 2015
[windows only] Require fails to load native addons with path longer than 260 characters #2964
Closed

mhdawson mentioned this pull request Nov 4, 2015
test\addons\load-long-path\test.js - windows 32 bit failures #3667
Closed

justinmchase deleted the use-long-path-to-load-addons branch February 5, 2016 17:17

Uh oh!

Uh oh!

Conversation

justinmchase commented Sep 19, 2015

Uh oh!

targosSep 19, 2015

Choose a reason for hiding this comment

Uh oh!

justinmchaseSep 19, 2015

Choose a reason for hiding this comment

Uh oh!

justinmchase commented Sep 19, 2015

Uh oh!

Fishrock123 commented Sep 20, 2015

Uh oh!

justinmchase commented Sep 20, 2015

Uh oh!

justinmchase commented Sep 24, 2015

Uh oh!

justinmchase commented Sep 24, 2015

Uh oh!

Fishrock123 commented Sep 24, 2015

Uh oh!

justinmchase commented Sep 24, 2015

Uh oh!

bnoordhuisSep 30, 2015

Choose a reason for hiding this comment

Uh oh!

justinmchaseSep 30, 2015

Choose a reason for hiding this comment

Uh oh!

thefourtheyeOct 2, 2015

Choose a reason for hiding this comment

Uh oh!

justinmchaseOct 2, 2015

Choose a reason for hiding this comment

Uh oh!

bnoordhuis commented Sep 30, 2015

Uh oh!

thefourtheye commented Sep 30, 2015

Uh oh!

piscisaureus commented Sep 30, 2015

Uh oh!

justinmchase commented Sep 30, 2015

Uh oh!

benjamingr commented Sep 30, 2015

Uh oh!

bnoordhuis commented Oct 1, 2015

Uh oh!

orangemocha commented Oct 1, 2015

Uh oh!

justinmchase commented Oct 1, 2015

Uh oh!

justinmchase commented Oct 2, 2015

Uh oh!

bnoordhuis commented Oct 3, 2015

Uh oh!

Fishrock123 commented Oct 5, 2015

Uh oh!

bnoordhuis commented Oct 5, 2015

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants