SWBUtil: use FileManager for more operations
#189
Conversation
compnerd
requested review from
jakepetroules,
mirza-garibovic,
mhrawdon,
neonichu and
owenv
as code owners
|
This is an extended change split out from the #184 based on @jakepetroules' comment that the use of raw C APIs is no longer a design constraint. This generally reduces complexity as |
|
@swift-ci please test |
That alone is a big reason to do this, I completely forgot about the POSIX APIs not handling long paths! |
|
@swift-ci test |
| // If the item at the path is a symlink, then we check whether it's a broken symlink or points to something that is not a directory. | ||
| if destinationExists { | ||
| // The destination does exist, so it's not a directory. | ||
| throw StubError.error("File is a symbolic link which references a path which is not a directory: \(path.str)") |
There was a problem hiding this comment.
Test expectations need to be updated to accommodate these specific error strings going away.
There was a problem hiding this comment.
Hmm, I don't see a good way to handle the check. There is no guarantee that the message is going to be identical across platforms and Foundation implementations :(
There was a problem hiding this comment.
I think it's fine if we just check that it does fail in the expected cases without checking the specific error string.
`unlink` is deprecated on Windows, and `RemoveFileW` should be preferred. However, that would limit the path to `MAX_PATH` (261) characters. Prefer to use `FileManager to remove the file to avoid the path limit. Adopt the fileManager path in more locations.
|
@swift-ci please test |
unlinkis deprecated on Windows, andRemoveFileWshould be preferred. However, that would limit the path toMAX_PATH(261) characters. Prefer to use `FileManager to remove the file to avoid the path limit.Adopt the fileManager path in more locations.