Running Path.resolve on a junctioned path in Windows 10 yields the "true" path, rather than the path that as seen from the working directory. This means that anything that checks whether a path is located relative to another path may fail, even though the junctions were set up in a way where this should absolutely not be the case.
This is particularly obvious when running web servers with static directories, so a demonstrator:
var Path = require('path');
var cwd = __dirname;
var fullPath = Path.resolve(cwd);
console.log(fullPath);
- have two drives, C: and D:
- create a
D:\junctions\git\test\ dir
- in
C:\Users\YourName\Documents\, create a directory junction git <==> D:\junctions\git
- cd into
C:\Users\YourName\Documents\git\test
- run
node test.js
While this should output C:\Users\YourName\Documents\git\test\, because that's what symlinks/junctions are used for (using paths as if they are local to somewhere they are not local to) it will instead output the original D:\junctions\git\projects\test path.
For a practical demonstration of how this ruins the fun, the Hapi inert middleware (responsible for static file serving) grinds to a halt on this because it sees an attempt to load a file that we as users think we've housed in a project-local directory, except Path.resolve turns that local path into a path on a completely different drive, massively violating containment rules and leading to a situation that requires diving into node_modules dir and debugging code two dependencies deep, only to find Node itself is doing the wrong thing =)
So, as the documentation for Path.resolve does not mention what it will do with symlinks, this is both a bug report and a request:
- can we fix
Path.resolve so that it generates a proper path, only asking for the true resource path belonging to a symlink/junction when an option is passed to enable that? And,
- can we update the documentation for
Path.resolve to mention what it does when it encounters a symlink or junction, so that developers know what behaviour can be expected from the Path module when it comes to "fake paths"?
Running
Path.resolveon a junctioned path in Windows 10 yields the "true" path, rather than the path that as seen from the working directory. This means that anything that checks whether a path is located relative to another path may fail, even though the junctions were set up in a way where this should absolutely not be the case.This is particularly obvious when running web servers with static directories, so a demonstrator:
D:\junctions\git\test\dirC:\Users\YourName\Documents\, create a directory junctiongit<==>D:\junctions\gitC:\Users\YourName\Documents\git\testnode test.jsWhile this should output
C:\Users\YourName\Documents\git\test\, because that's what symlinks/junctions are used for (using paths as if they are local to somewhere they are not local to) it will instead output the originalD:\junctions\git\projects\testpath.For a practical demonstration of how this ruins the fun, the Hapi
inertmiddleware (responsible for static file serving) grinds to a halt on this because it sees an attempt to load a file that we as users think we've housed in a project-local directory, exceptPath.resolveturns that local path into a path on a completely different drive, massively violating containment rules and leading to a situation that requires diving intonode_modulesdir and debugging code two dependencies deep, only to find Node itself is doing the wrong thing =)So, as the documentation for
Path.resolvedoes not mention what it will do with symlinks, this is both a bug report and a request:Path.resolveso that it generates a proper path, only asking for the true resource path belonging to a symlink/junction when an option is passed to enable that? And,Path.resolveto mention what it does when it encounters a symlink or junction, so that developers know what behaviour can be expected from the Path module when it comes to "fake paths"?