-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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.
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
Resolve sandbox issues on external volumes #6773
Conversation
swiftlang/swift-tools-support-core#427 |
swiftlang/swift-tools-support-core#427 |
@swift-ci please smoke test |
Feels like we need a bot to re-run CI at this point... |
@swift-ci please smoke test |
Swift CI is still broken for us |
@swift-ci smoke test linux |
@swift-ci please smoke test |
@swift-ci please smoke test macOS |
@swift-ci smoke test macos |
Looks like this test failure must be caused by these changes:
|
The sandbox profile SwiftPM generates curates the directories plugins and manifests are able to write to. Several Foundation APIs use a so-called "item replacement directory" when doing atomic operations and this happens to be a special path on the same volume when performing operations on an external volume. This lead to those operations being blocked in plugins which does not seem right since those item replacement directories are temporary directories in spirit. We now automatically allow writes for those when generating a sandbox profile. rdar://112217177
a23d3c0
to
ebf511b
Compare
Ah, figured out the issue now: we also generate a sandbox profile for manifest loading and that can happen with virtual paths of course for which determining the item replacement directory fails, but the error was caught at a higher level and lead to the confusing test outcome. I changed this now to ignore any errors when determining the item replacement directories which resolves this but also seems like the correct behavior since those errors shouldn't be fatal. |
@swift-ci please smoke test |
@swift-ci please smoke test windows |
The sandbox profile SwiftPM generates curates the directories plugins and manifests are able to write to. Several Foundation APIs use a so-called "item replacement directory" when doing atomic operations and this happens to be a special path on the same volume when performing operations on an external volume. This lead to those operations being blocked in plugins which does not seem right since those item replacement directories are temporary directories in spirit. We now automatically allow writes for those when generating a sandbox profile.
rdar://112217177