-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
lib/std: Make usage of PermissionDenied & AccessDenied consistent #23007
base: master
Are you sure you want to change the base?
Conversation
6fc21ea
to
bcb07ec
Compare
The x86_64-macos-release failure is:
I believe this is failing to build an executable for the Once the other CI builds for this PR complete, I'll rebase this PR and push another version and hope this goes away. If anyone wants me to file a bug or dig into this failure more (or knows what's going on), please let me know. |
That could just be OOM fallout. That particular test hasn't had any issues since I introduced it. |
Windows defines an `ACCESS_DENIED` error code. There is no PERMISSION_DENIED (or its equivalent) which seems to only exist on POSIX systems. Fix a couple Windows calls code to return `error.AccessDenied` for `ACCESS_DENIED` and to stop mapping AccessDenied into PermissionDenied.
…rmissionDenied Use error.AccessDenied for permissions (rights) failures on Wasi (`EACCES`) and error.PermissionDenied (`EPERM`) for systemic failures. And pass-through underlying Wasi errors (PermissionDenied or AccessDenied) without mapping.
This PR consistently maps .ACCES into AccessDenied and .PERM into PermissionDenied. AccessDenied is returned if the file mode bit (user/group/other rwx bits) disallow access (errno was `EACCES`). PermissionDenied is returned if something else denies access (errno was `EPERM`) (immutable bit, SELinux, capabilities, etc). This somewhat subtle distinction is a POSIX thing. Most of the change is updating std.posix Error Sets to contain both errors, and then propagating the pair up through caller Error Sets. Fixes ziglang#16782
bcb07ec
to
187124b
Compare
This PR (mostly) consistently maps
.ACCES
intoerrors.AccessDenied
and.PERM
intoerrors.PermissionDenied
. These two similar error codes are a POSIX thing whereEACCES
is returned if the file mode bits (user/group/other rwx bits) disallow access. WhereasEPERM
is returned if something else denies access (e.g., immutable bit, SELinux, capabilities, etc). Most of the change is straight-forward and starts in the lib/std/posix.zig code, and propagates up to the std.os.* and std.fs.* layers that pass the Posix errors on. There are a couple pre-existing exceptions to this general rule where more "useful" errors are returned (e.g.,errors.Locked
forEACCES
infcntl
).POSIX makes this extra confusing because the
EACCES
errno stringifies as "Permission Denied" (EPERM
stringifies as "Operation Not Permitted"). I think it is clearer to map the Zig made up names to the errno token, thusAccessDenied
forEACCES
andPermissionDenied
forEPERM
, but I could be persuaded to use a different mapping. OTOH, I think it would be even less confusing if Zig didn't try to "fix" the errno names and just returnederrors.EACCES
anderrors.EPERM
, but that is not this PR.I changed some Windows code (both in posix.zig and not) to consistently map the Windows
ACCESS_DENIED
error code toerrors.AccessDenied
. My general rule here is that the Zig error codes should reflect the platform's error as directly as possible unless there is a good reason.Fixes #16782