The path string returned when nan is imported in node 6 is wrong in some cases

[amatas]

Addressing this: #600

With the old method to get the current directory of 'nan' module, the path isn't got properly when the parent path is in a shared resource:

vboxsrv\vagrant\NODE_MODULES\nan (which don't exists)

with the new method the current directory is obtained correctly:
\\vboxsrv\vagrant\NODE_MODULES\nan

This change makes that packages like bufferutil or ref are built correctly as they are able to get the nan headers if the working directory is inside a network resource.

[bnoordhuis]

LGTM but it wouldn't hurt to get one or two more people to sign off on this.

Can you update the commit log to explain what you changed and why? See git log for examples of the expected format.

[TooTallNate]

Sounds like a bug in path.relative() to me. If it's given an absolute network file path then it should return it untouched, I would think.

[bnoordhuis]

I speculate (but am not 100% sure) the realpath changes in v6 are responsible.

path.relative('.', __dirname) calls path.resolve() on both arguments. After the switch to uv_fs_realpath(), __dirname sometimes is not what it used to be on network drives and substituted drives.

I wonder though if simply console.log(__dirname) wouldn't suffice? It's guaranteed to be an absolute path.

[amatas]

Can you update the commit log to explain what you changed and why?

Done!

I speculate (but am not 100% sure) the realpath changes in v6 are responsible.

I believe so, I've tested the method with the following results:

* Windows 10 with node 4.3.0:
  c:\>node -e "console.log(require('path').relative('.','\\\\VBOXSRV\\vagrant'))"
  returns: \\VBOXSRV\vagrant\

* Windows 10 with node 6.5.0:
  c:\>node -e "console.log(require('path').relative('.','\\\\VBOXSRV\\vagrant'))"
  returns: VBOXSRV\vagrant\

[amatas]

Sorry, I pressed the wrong button

[amatas]

I've done some tests with the console.log(__dirname) and seems to work fine as well, with the advantage that it doesn't depend on the methods of the Path module. Do you all think that this could be the best solution?

[bnoordhuis]

@rvagg I think you are the original author? Maybe you can chime in?