-
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
Inconsistent results for path.toNamespacedPath() for win32 UNC paths #30224
Comments
Suggest, in path.js:
|
p.s.
works fine.... so UNC paths are all good. |
5 tasks
targos
added
path
Issues and PRs related to the path subsystem.
windows
Issues and PRs related to the Windows platform.
labels
Dec 26, 2020
eliphazbouye
pushed a commit
to eliphazbouye/node
that referenced
this issue
Jun 20, 2024
PR-URL: nodejs#52915 Fixes: nodejs#30224 Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
bmeck
pushed a commit
to bmeck/node
that referenced
this issue
Jun 22, 2024
PR-URL: nodejs#52915 Fixes: nodejs#30224 Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
when using UNC paths, the function path.toNamespacedPath() gives different results from non UNC paths.
This is reproduced by running the code attached below.
Basically, most of the time in Node, you can freely use '/' and '', and most repos just use '/', for example this snippet:
fs.readdirSync(__dirname + '/grant').forEach(function(filename) {
from
https://github.com/jaredhanson/oauth2orize/blob/master/lib/index.js
The issue is that if the path being accessed is a UNC style (actually, problem is only if accessed pre-namespaced?) path, then the '/' does not get translated to a '' on windows. If the path is a 'normal' drive based windows path, then the '/' is replaced by '' in path.toNamespacedPath(), which is used by most fs functions to qualify a path, and so there is no issue.
As you can see from the results of the simple tests, path.win32.resolve('\\?\c:\Windows/System') returns '\\?\c:\Windows\System'.
path.toNamespacedPath(path) uses this internally, but returns path, not resolvedPath in this circumstance. So the resulting path from path.toNamespacedPath('\\?\c:\Windows/System') is '\\?\c:\Windows/System' - which is invalid.
(I will post a proposed solution in the next comment).
Simple example test:
on a windows system, run the following code:
The text was updated successfully, but these errors were encountered: