Foundation: support file system representation for long paths #4746
Conversation
This adjusts the file system representation accessor for a URL to support paths beyond `MAX_PATH`. We do not know what the use of the file system representation is, so we cannot provide the NT style path (`\\?\`-prefixed). Rather than using the filled in buffer, resolve the URL and then build the complete path copying that into a newly allocated buffer. This ensures that we always have sufficient space for the path without having to grow the buffer. Linux gets away with the current implementation by setting the `PATH_MAX` to page size (4096). There may be some value in using the single implementation across the different platforms, but this will allow the Windows path to make progress even if it diverges from the reference implementation. The issue was identified by the DocC test suite which quickly exceeds the length.
|
@swift-ci please test |
| #if os(Windows) | ||
| let bufSize = Int(MAX_PATH + 1) | ||
| if let resolved = CFURLCopyAbsoluteURL(_cfObject), |
There was a problem hiding this comment.
Can we add a comment here explaining why the Windows behavior needs to be different here but not in _wideFileSystemRepresentation?
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
This adjusts the file system representation accessor for a URL to support paths beyond
MAX_PATH. We do not know what the use of the file system representation is, so we cannot provide the NT style path (\\?\-prefixed). Rather than using the filled in buffer, resolve the URL and then build the complete path copying that into a newly allocated buffer. This ensures that we always have sufficient space for the path without having to grow the buffer.Linux gets away with the current implementation by setting the
PATH_MAXto page size (4096). There may be some value in using the single implementation across the different platforms, but this will allow the Windows path to make progress even if it diverges from the reference implementation.The issue was identified by the DocC test suite which quickly exceeds the length.