Strip any UNC long path prefix from _wgetcwd #5267
Conversation
daveinglis
commented
Sep 16, 2025
daveinglis
commented
- This keeps any UNC long file or device prefix (\?\ and \.) out of URL that were relative and then resolved to absolute urls.
|
@swift-ci test |
|
Could we add tests for this? |
daveinglis
force-pushed
the
strip_unc_lf_preifx
branch
from
5ee648b to
d4a2ea5
Compare
|
test added |
|
@swift-ci test |
daveinglis
force-pushed
the
strip_unc_lf_preifx
branch
2 times, most recently
from
a02ed6f to
82bf6bf
Compare
- This keeps any UNC long file or device prefix (\\?\) out of URL that were relative and then resolved to absolute urls.
daveinglis
force-pushed
the
strip_unc_lf_preifx
branch
from
82bf6bf to
88dcf1b
Compare
|
@swift-ci test |
|
@swift-ci test windows |
|
@swift-ci test linux |
|
@swift-ci test |
|
|
||
| // Get original directory for restoration | ||
| var originalBuffer = [CChar](repeating: 0, count: Int(MAX_PATH)) | ||
| guard _NS_getcwd(&originalBuffer, originalBuffer.count) != nil else { |
There was a problem hiding this comment.
What's the user level API that this is supposed to affect? _NS_getcwd is clearly for internal use only.
There was a problem hiding this comment.
it looks like NSURL::fileSystemRepresentation with a relative path would use it to make it absolute, could be other places too but it was that test that was failing due to the long path prefix
There was a problem hiding this comment.
Instead of calling directly to _NS_getcwd from the test, it'd be great if this test could call the client-level API that this affects. So if changing _NS_getcwd is required here because it impacts the FSR of an NSURL, could we instead write a test that checks the output of NSURL's FSR to ensure it's the right value? To me that would be a more valuable unit test to make sure the client level behavior is correct regardless of the output of this function (since as we remove more and more C code this function may go away, but our Swift API won't)
|
So the swift API that would be affected was going to have this as well (FileManager.currentDirectoryPath - see swiftlang/swift-foundation#1479) but that PR also cause the NSURL test to fail so it was reverted (swiftlang/swift-foundation#1512) until a fix could be put in place (this). |
|
@swift-ci test |
|
@parkera Is my last comment clear on where this prefix is originating from? I would like to resurrect this (swiftlang/swift-foundation#1479) foundation change that was reverted once this goes in. |
| } | ||
|
|
||
| // Strip UNC long path prefixe (\\?\) from the wide character buffer using PathCchStripPrefix | ||
| wchar_t *pathToConvert = buf; |
There was a problem hiding this comment.
Instead of adding to this _NS_getcwd, I wonder if we should just make this call to the implementation in swift-foundation. Is it feasible to call from CF to a Foundation @_cdecl function here? That way it could call to swift-foundation via FileManager and then we'd be using the same "get CWD" implementation everywhere instead of maintaining two copies of it.
|
|
||
| // Get original directory for restoration | ||
| var originalBuffer = [CChar](repeating: 0, count: Int(MAX_PATH)) | ||
| guard _NS_getcwd(&originalBuffer, originalBuffer.count) != nil else { |
There was a problem hiding this comment.
Instead of calling directly to _NS_getcwd from the test, it'd be great if this test could call the client-level API that this affects. So if changing _NS_getcwd is required here because it impacts the FSR of an NSURL, could we instead write a test that checks the output of NSURL's FSR to ensure it's the right value? To me that would be a more valuable unit test to make sure the client level behavior is correct regardless of the output of this function (since as we remove more and more C code this function may go away, but our Swift API won't)
4 participants
