[Windows] Standardize slashes before path processing #731
Conversation
jmschonfeld
force-pushed
the
windows/path-standardization
branch
from
6a0ae90 to
d72791a
Compare
jmschonfeld
changed the title
|
@swift-ci please test |
| @@ -282,10 +282,16 @@ final class FileManagerTests : XCTestCase { | |||
| try $0.createDirectory(atPath: "create_dir_test2/nested2", withIntermediateDirectories: true) | |||
| XCTAssertEqual(try $0.contentsOfDirectory(atPath: "create_dir_test2").sorted(), ["nested", "nested2"]) | |||
| XCTAssertNoThrow(try $0.createDirectory(atPath: "create_dir_test2/nested2", withIntermediateDirectories: true)) | |||
|
|
|||
| #if os(Windows) | |||
| try $0.createDirectory(atPath: "create_dir_test3\\nested", withIntermediateDirectories: true) | |||
There was a problem hiding this comment.
This is an example of a previous API that used to fail without this change. Previously, this API called deletingLastPathComponent on the provided path, which would return an empty string and therefore fail to create the parent create_dir_test3 directory. Now it correctly creates create_dir_test3 followed by create_dir_test3/nested
| let beforeDot = pathExtension[..<lastDot].unicodeScalars | ||
| let afterDot = pathExtension[pathExtension.index(after: lastDot)...].unicodeScalars | ||
| let beforeDot = pathExtension[..<lastDot]._standardizingSlashes().unicodeScalars | ||
| let afterDot = pathExtension[pathExtension.index(after: lastDot)...]._standardizingSlashes().unicodeScalars |
There was a problem hiding this comment.
Where do we expect an arc separator after the extension separator? That is, the extension should be on the final arc, and so there would be no slashes right?
There was a problem hiding this comment.
We don't expect it to occur, but this is to ensure that we validate that it doesn't. I can't come up with any scenarios where we would currently end up in this situation, but invalidExtensionScalars contains a / and so to ensure that POSIX and Windows behaviors are consistent, I added this standardization here so that if we do somehow end up with a \ in the path extension that we mark it as invalid on Windows
|
@swift-ci please test |
|
@swift-ci please test |
All of our
String-based path processing assumes that the paths are standardized to forward slashes, however there are many sources (such asFileManager) where these paths may come in on Windows with backslashes resulting in incorrect path manipulation. This updates all of these functions to standardize to forward slashes where needed when performing path-related functions. On windows, these slashes will already be automatically changed back to backslashes if necessary by the file system representation functions.Note: this currently doesn't handle drive letters any differently than other path components. We can probably do better there, but this at least unblocks the toolchain work and gets us on-par with what SCL-F used to do