System.Posix.Files.fileAccess fails inside OS X sandbox #18
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The ByteString variant of the access function didn't accept the same flags as the non-ByteString one, but it makes sense that the OS doesn't care about which one is being used and returns all error codes for both variants.
This is useful on OS X when its sandboxing mechanism is used, because that will set errno = EPERM when a file can't be written due to sandboxing (as opposed to setting it to EACCES when file permissions deny writing).
|
patch is fine here :-) |
|
Shameless bump :) |
hvr
added a commit
that referenced
this pull request
Nov 7, 2014
`System.Posix.Files.fileAccess` fails inside OS X sandbox
|
thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi,
similar to what has been reported in https://ghc.haskell.org/trac/ghc/ticket/8741, the same code fails when run inside OS X' sandboxing mechanism because
access(2)sets errno toEPERMrather thanEACCESwhen access is denied due to sandboxing rules rather than file modes.As with the ticket referenced above, this breaks Cabal on OS X when used inside a sandbox (which is the case for every MacPorts port):
The top commit adds
ePERMas another errno value to be handled gracefully. Since the same code exists in the ByteString variant of the interface, I've also changed it there (and ported the change from #8741, which was also missing). I took the liberty of removing the remaining tabs in this file, because there still were some in the block I changed.I'm not sure whether this is the right place to open this ticket (http://hackage.haskell.org/package/unix says it is, #8741 in GHC Trac suggests it isn't), so please let me know if I should take this patch elsewhere.