Skip to content

Foundation: support file system representation for long paths #4746

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Jun 4, 2023
Merged

Foundation: support file system representation for long paths #4746

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 8 additions & 3 deletions Sources/Foundation/NSURL.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -481,19 +481,24 @@ open class NSURL : NSObject, NSSecureCoding, NSCopying {

// Memory leak. See https://github.com/apple/swift-corelibs-foundation/blob/master/Docs/Issues.md
open var fileSystemRepresentation: UnsafePointer<Int8> {

#if os(Windows)
let bufSize = Int(MAX_PATH + 1)
if let resolved = CFURLCopyAbsoluteURL(_cfObject),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add a comment here explaining why the Windows behavior needs to be different here but not in _wideFileSystemRepresentation?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect that the `_wideFileSystemRepresentation will need to change. At that point, I'm more tempted to remove that function. Having different variants of the functions makes things more difficult to correctly refactor. That is, this is far more surgical than ideal. I can add a note on the wide variant that it needs to be updated and ideally removed.

The honest answer is: fixing a bug at a time. The reality is that most of the file system access routines for Windows need to be adjusted to use the NT path spelling, but that is also a good time to clean up some of the implementation to make it a bit less egregiously pessimistic (e.g. reusing encoded file paths, reusing stat information, etc).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussed this offline - I'll add the comment in a follow up. This is the first step towards fixing all the various cases in this file. The work is going to enable DocC and should also help potentially help make SPM and driver more reliable on Windows with extended paths.

let representation = CFURLCopyFileSystemPath(resolved, kCFURLWindowsPathStyle)?._swiftObject {
let buffer = UnsafeMutablePointer<Int8>.allocate(capacity: representation.count + 1)
representation.withCString { buffer.initialize(from: $0, count: representation.count + 1) }
buffer[representation.count] = 0
return UnsafePointer(buffer)
}
#else
let bufSize = Int(PATH_MAX + 1)
#endif

let _fsrBuffer = UnsafeMutablePointer<Int8>.allocate(capacity: bufSize)
_fsrBuffer.initialize(repeating: 0, count: bufSize)

if getFileSystemRepresentation(_fsrBuffer, maxLength: bufSize) {
return UnsafePointer(_fsrBuffer)
}
#endif

// FIXME: This used to return nil, but the corresponding Darwin
// implementation is marked as non-nullable.
Expand Down