Simplify a few API calls in FSProxy #427
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jakepetroules
requested review from
mhrawdon,
mirza-garibovic,
neonichu and
owenv
as code owners
Collaborator
Author
|
@swift-ci test |
neonichu
approved these changes
Apr 22, 2025
jakepetroules
force-pushed
the
win32-api-usage-fsproxy
branch
from
7c9a5f3 to
ab1e889
Compare
Collaborator
Author
|
@swift-ci test |
compnerd
approved these changes
Apr 22, 2025
jakepetroules
force-pushed
the
win32-api-usage-fsproxy
branch
from
ab1e889 to
6633142
Compare
Collaborator
Author
|
@swift-ci test |
jakepetroules
force-pushed
the
win32-api-usage-fsproxy
branch
from
6633142 to
e42301e
Compare
Collaborator
Author
|
@swift-ci test |
jakepetroules
force-pushed
the
win32-api-usage-fsproxy
branch
from
e42301e to
addb855
Compare
Collaborator
Author
|
@swift-ci test |
These now go through Foundation rather than Win32 APIs directly. This simplifies Unicode and long path handling in particular. For realpath I left the POSIX implementation in place for non-Windows for now since it's not clear that has equivalent behavior. touch/setFileTimestamp now differ in that they no longer set atime, but virtually nothing uses atime.
jakepetroules
force-pushed
the
win32-api-usage-fsproxy
branch
from
addb855 to
3cc21fb
Compare
Collaborator
Author
|
@swift-ci test |
jakepetroules
added a commit
to jakepetroules/swift-build
that referenced
this pull request
Nov 4, 2025
This regressed as part of swiftlang#427, which attempted to simplify API calls in FSProxy to use Foundation rather than bespoke implementations going directly to Win32/POSIX API. However, `standardizingPath` on Windows doesn't actually handle 8.3 filenames correctly, and so Swift Build doesn't know (for example) that C:\Users\JAKEPE~1 and C:\Users\jakepetroules are the same path. Use the canonicalPathKey from URLResourceValues to canonicalize the path appropriately on both platforms, which under the hood uses GetFinalPathNameByHandleW on Windows and realpath on POSIX, matching the previous behavior. With this change, the androidCommandLineTool test now passes on Windows, which was previously failing due to differences between paths in 8.3 form vs long form.
jakepetroules
added a commit
to jakepetroules/swift-build
that referenced
this pull request
Nov 4, 2025
This regressed as part of swiftlang#427, which attempted to simplify API calls in FSProxy to use Foundation rather than bespoke implementations going directly to Win32/POSIX API. However, `standardizingPath` on Windows doesn't actually handle 8.3 filenames correctly, and so Swift Build doesn't know (for example) that C:\Users\JAKEPE~1 and C:\Users\jakepetroules are the same path. Use the canonicalPathKey from URLResourceValues to canonicalize the path appropriately on both platforms, which under the hood uses GetFinalPathNameByHandleW on Windows and realpath on POSIX, matching the previous behavior. With this change, the androidCommandLineTool test now passes on Windows, which was previously failing due to differences between paths in 8.3 form vs long form.
jakepetroules
added a commit
to jakepetroules/swift-build
that referenced
this pull request
Nov 4, 2025
This regressed as part of swiftlang#427, which attempted to simplify API calls in FSProxy to use Foundation rather than bespoke implementations going directly to Win32/POSIX API. However, `standardizingPath` on Windows doesn't actually handle 8.3 filenames correctly, and so Swift Build doesn't know (for example) that C:\Users\JAKEPE~1 and C:\Users\jakepetroules are the same path. Use the canonicalPathKey from URLResourceValues to canonicalize the path appropriately on both platforms, which under the hood uses GetFinalPathNameByHandleW on Windows and realpath on POSIX, matching the previous behavior. With this change, the androidCommandLineTool test now passes on Windows, which was previously failing due to differences between paths in 8.3 form vs long form.
jakepetroules
added a commit
to jakepetroules/swift-build
that referenced
this pull request
Nov 4, 2025
This regressed as part of swiftlang#427, which attempted to simplify API calls in FSProxy to use Foundation rather than bespoke implementations going directly to Win32/POSIX API. However, `standardizingPath` on Windows doesn't actually handle 8.3 filenames correctly, and so Swift Build doesn't know (for example) that C:\Users\JAKEPE~1 and C:\Users\jakepetroules are the same path. Use the canonicalPathKey from URLResourceValues to canonicalize the path appropriately on both platforms, which under the hood uses GetFinalPathNameByHandleW on Windows and realpath on POSIX, matching the previous behavior. With this change, the androidCommandLineTool test now passes on Windows, which was previously failing due to differences between paths in 8.3 form vs long form.
jakepetroules
added a commit
to jakepetroules/swift-build
that referenced
this pull request
Nov 4, 2025
This regressed as part of swiftlang#427, which attempted to simplify API calls in FSProxy to use Foundation rather than bespoke implementations going directly to Win32/POSIX API. However, `standardizingPath` on Windows doesn't actually handle 8.3 filenames correctly, and so Swift Build doesn't know (for example) that C:\Users\JAKEPE~1 and C:\Users\jakepetroules are the same path. Use the canonicalPathKey from URLResourceValues to canonicalize the path appropriately on both platforms, which under the hood uses GetFinalPathNameByHandleW on Windows and realpath on POSIX, matching the previous behavior. With this change, the androidCommandLineTool test now passes on Windows, which was previously failing due to differences between paths in 8.3 form vs long form.
jakepetroules
added a commit
that referenced
this pull request
Nov 5, 2025
This regressed as part of #427, which attempted to simplify API calls in FSProxy to use Foundation rather than bespoke implementations going directly to Win32/POSIX API. However, `standardizingPath` on Windows doesn't actually handle 8.3 filenames correctly, and so Swift Build doesn't know (for example) that C:\Users\JAKEPE~1 and C:\Users\jakepetroules are the same path. Use the canonicalPathKey from URLResourceValues to canonicalize the path appropriately on both platforms, which under the hood uses GetFinalPathNameByHandleW on Windows and realpath on POSIX, matching the previous behavior. With this change, the androidCommandLineTool test now passes on Windows, which was previously failing due to differences between paths in 8.3 form vs long form.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These now go through Foundation rather than Win32 APIs directly. This simplifies Unicode and long path handling in particular.
For realpath I left the POSIX implementation in place for non-Windows for now since it's not clear that has equivalent behavior. touch/setFileTimestamp now differ in that they no longer set atime, but virtually nothing uses atime.