-
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
path: fix win32 volume-relative paths #14440
Conversation
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.
Thanks for working on this!
['C:\\path\\dir\\index.html', 'C:\\'], | ||
['C:\\another_path\\DIR\\1\\2\\33\\\\index', 'C:\\'], | ||
['another_path\\DIR with spaces\\1\\2\\33\\index', ''], | ||
['\\foo\\C:', '\\'], |
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.
I don't think this is a valid Windows path, is it?
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.
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.
I don't mean we should validate it, I just don't think we should test against invalid paths.
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.
I don't see any harm in having it here. In fact we should keep it just for compatibility until some future fix that needs to remove it.
['C:abc', 'C:'], | ||
['C:\\', 'C:\\'], | ||
['C:\\abc', 'C:\\' ], | ||
['', ''], |
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.
Could you add tests for NTFS alterate streams? e.g. ['cd:foo', '']
. Not just to test root
, but also the other properties used in checkParseFormat
.
assert.strictEqual(path.win32.basename('C:basename.ext'), 'basename.ext'); | ||
assert.strictEqual(path.win32.basename('C:basename.ext\\'), 'basename.ext'); | ||
assert.strictEqual(path.win32.basename('C:basename.ext\\\\'), 'basename.ext'); | ||
assert.strictEqual(path.win32.basename('C:foo'), 'foo'); |
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.
Again, a test for NTFS alternate streams would be nice: basename('cd:foo') === 'cd:foo'
['C:\\path\\dir\\index.html', 'C:\\'], | ||
['C:\\another_path\\DIR\\1\\2\\33\\\\index', 'C:\\'], | ||
['another_path\\DIR with spaces\\1\\2\\33\\index', ''], | ||
['\\foo\\C:', '\\'], |
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.
@@ -406,6 +422,11 @@ assert.strictEqual(path.win32.normalize('a//b//.'), 'a\\b'); | |||
assert.strictEqual(path.win32.normalize('//server/share/dir/file.ext'), | |||
'\\\\server\\share\\dir\\file.ext'); | |||
assert.strictEqual(path.win32.normalize('/a/b/c/../../../x/y/z'), '\\x\\y\\z'); |
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.
Optional:
Could you parameterize this part like the others are:
[[a,b]].forEach(([tested, expected]) => ...
(not the scope of this PR but still would be nice)
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.
I'd rather leave that to a dedicated PR, as there are many other tests that do not use this pattern in the file.
const output = path.parse(element); | ||
assert.strictEqual(typeof output.root, 'string'); | ||
assert.strictEqual(typeof output.dir, 'string'); | ||
assert.strictEqual(typeof output.base, 'string'); | ||
assert.strictEqual(typeof output.ext, 'string'); | ||
assert.strictEqual(typeof output.name, 'string'); | ||
assert.strictEqual(path.format(output), element); | ||
assert.strictEqual(output.root, root); | ||
assert.strictEqual(output.dir.indexOf(output.root), 0); |
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.
could you use startsWith
, so it won't pop up when grepping for indexOf
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.
I don't quite know the reason for grepping indexOf
, but changed nevertheless.
@TimothyGu could you run performance comparison, just for reference? |
P.S. thanks for doing this 👍! Playing with |
@refack For good measure:
|
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.
Thank you
However: improvement confidence p.value
path/extname-win32.js n=1000000 path="" -74.64 % *** 1.674087e-26
path/extname-win32.js n=1000000 path="\\\\" -4.91 % *** 1.755024e-07
path/extname-win32.js n=1000000 path="\\\\foo\\\\bar\\\\baz\\\\asdf\\\\quux.foobarbazasdfquux" -7.25 % *** 1.823382e-05
path/extname-win32.js n=1000000 path="C:\\\\foo" -21.36 % *** 5.547522e-18
path/extname-win32.js n=1000000 path="D:\\\\foo\\\\bar\\\\baz\\\\asdf\\\\quux" -23.40 % *** 3.036449e-06
path/extname-win32.js n=1000000 path="foo\\\\.bar.baz" -7.85 % *** 1.491586e-14
path/extname-win32.js n=1000000 path="foo\\\\bar\\\\...baz.quux" -12.20 % *** 4.673165e-05
path/extname-win32.js n=1000000 path="foo\\\\bar\\\\..baz.quux" -11.68 % *** 1.828409e-13
path/extname-win32.js n=1000000 path="index.html" -8.17 % *** 1.836566e-09
path/extname-win32.js n=1000000 path="index" -7.79 % * 2.396233e-02 There isn't anything I can do to improve the worst case (
|
Since this is a bug fix IMHO we can absorb the performance degradation for this case. Especially since the most common case doesn't take a bit hit (and the absolute numbers are probably tiny anyway): path/extname-win32.js n=1000000 path="index.html" -8.17 % *** 1.836566e-09 |
@TimothyGu This would need to be rebased ;) |
@TimothyGu My bad, sorry, I landed f7f590c this morning. You can safely drop my changes to |
`path.resolve()` and `path.join()` are left alone in this commit due to the lack of clear semantics. Fixes: nodejs#14405
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.
LGTM, no opinion on performance. Thanks for fixing this :)
Landed in 2791761. |
`path.resolve()` and `path.join()` are left alone in this commit due to the lack of clear semantics. PR-URL: #14440 Fixes: #14405 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
`path.resolve()` and `path.join()` are left alone in this commit due to the lack of clear semantics. PR-URL: #14440 Fixes: #14405 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
This does not land cleanly in LTS. Please feel free to manually backport by following the guide. Please also feel free to replace do-not-land if it is being backported |
@MylesBorins Done: #14787 |
`path.resolve()` and `path.join()` are left alone in this commit due to the lack of clear semantics. Backport-PR-URL: #14787 PR-URL: #14440 Fixes: #14405 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
`path.resolve()` and `path.join()` are left alone in this commit due to the lack of clear semantics. Backport-PR-URL: #14787 PR-URL: #14440 Fixes: #14405 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
This LTS release comes with 152 commits. This includes 75 which are test related, 25 which are doc related, 21 which are build / tool related and 3 commits which are updates to dependencies. Notable Changes: * build: - Codesigning is fixed on macOS (Evan Lucas) #14179 * deps: - Snapshots are turned back on!!! (Yang Guo) #14385 * path: - win32 volume-relative paths are working again! (Timothy Gu) #14440 * tools: - v6.x can now build with ICU 59 (Steven R. Loomis) #12078 PR-URL: #14852
This LTS release comes with 152 commits. This includes 75 which are test related, 25 which are doc related, 21 which are build / tool related and 3 commits which are updates to dependencies. Notable Changes: * build: - Codesigning is fixed on macOS (Evan Lucas) #14179 * deps: - Snapshots are turned back on!!! (Yang Guo) #14385 * path: - win32 volume-relative paths are working again! (Timothy Gu) #14440 * tools: - v6.x can now build with ICU 59 (Steven R. Loomis) #12078 PR-URL: #14852
This LTS release comes with 152 commits. This includes 75 which are test related, 25 which are doc related, 21 which are build / tool related and 3 commits which are updates to dependencies. Notable Changes: * build: - Codesigning is fixed on macOS (Evan Lucas) nodejs#14179 * deps: - Snapshots are turned back on!!! (Yang Guo) nodejs#14385 * path: - win32 volume-relative paths are working again! (Timothy Gu) nodejs#14440 * tools: - v6.x can now build with ICU 59 (Steven R. Loomis) nodejs#12078 PR-URL: nodejs#14852
`path.resolve()` and `path.join()` are left alone in this commit due to the lack of clear semantics. PR-URL: nodejs/node#14440 Fixes: nodejs/node#14405 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
path.resolve()
andpath.join()
are left alone in this commit due toa lack of clear semantics.
Fixes: #14405
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
path