`std.fs.accessAbsolute` when accessing forbidden file returns `error.Unexpected` but also prints stack trace

[giann]

Zig Version

0.14.0-dev.2989+bf6ee7cb3

Steps to Reproduce and Observed Behavior

const std = @import("std");

pub fn main() void {
    const term = "/usr/share/terminfo/78/xterm-256color";

    std.debug.print(
        "File {s} exists? {!}\n",
        .{
            term,
            std.fs.accessAbsolute(term, .{ .mode = .read_write }),
        },
    );
}

Here the file has only read permission for my user. accessAbsolute returns error.Unexpected and prints the stack trace:

$ zig run ~/tmp-code/exists.zig
unexpected errno: 1
/Users/giann/zig/master/lib/std/debug.zig:311:31: 0x100e41f87 in dumpCurrentStackTrace (exists)
        writeCurrentStackTrace(stderr, debug_info, io.tty.detectConfig(io.getStdErr()), start_addr) catch |err| {
                              ^
/Users/giann/zig/master/lib/std/posix.zig:7434:40: 0x100e571ab in unexpectedErrno (exists)
        std.debug.dumpCurrentStackTrace(null);
                                       ^
/Users/giann/zig/master/lib/std/posix.zig:4949:45: 0x100e71293 in faccessatZ (exists)
        else => |err| return unexpectedErrno(err),
                                            ^
/Users/giann/zig/master/lib/std/fs/Dir.zig:2481:36: 0x100e5492f in accessZ (exists)
    const result = posix.faccessatZ(self.fd, sub_path, os_mode, 0);
                                   ^
/Users/giann/zig/master/lib/std/fs/Dir.zig:2464:24: 0x100e42cd7 in access (exists)
    return self.accessZ(&path_c, flags);
                       ^
/Users/giann/zig/master/lib/std/fs.zig:305:21: 0x100e414db in accessAbsolute (exists)
    try cwd().access(absolute_path, flags);
                    ^
/Users/giann/tmp-code/exists.zig:10:34: 0x100e40b4b in main (exists)
            std.fs.accessAbsolute(term, .{ .mode = .read_write }),
                                 ^
/Users/giann/zig/master/lib/std/start.zig:647:22: 0x100e409a7 in main (exists)
            root.main();
                     ^
???:?:?: 0x189903fd7 in ??? (???)
???:?:?: 0xda197fffffffffff in ??? (???)
File /usr/share/terminfo/78/xterm-256color exists? error.Unexpected

Expected Behavior

Should not print the stack trace

[xdBronch]

this is just how unexpectedErrno works in general, its only in debug mode though

zig/lib/std/posix.zig

Lines 7471 to 7477 in 7ac110a

	pub fn unexpectedErrno(err: E) UnexpectedError {
	if (unexpected_error_tracing) {
	std.debug.print("unexpected errno: {d}\n", .{@intFromEnum(err)});
	std.debug.dumpCurrentStackTrace(null);
	}
	return error.Unexpected;
	}

unrelated but that really should be using @returnAddress() not null

[giann]

That's when an error payload would have been useful.

Anyway a missing permission is hardly "unexpected" should there not be a dedicated error for this?

[rootbeer]

Zig says unexpected errno: 1, and on my system (Linux) errno 1 is EPERM, I'm going to guess its the same on yours.

Zig's faccessatZ handles an EACCES ("access would be denied to the file, or a containing directory") but not an EPERM ("Write permission was requested to a file that has the immutable flag set.") Error interpretations were pulled from https://man.archlinux.org/man/faccessat.2.en.

There is an open question about supporting both AccessDenied and PermissionDenied in Zig (see #16782), but this syscall's failure seems like a good reason to maintain the distinction... Adding a new case for EPERM to faccessatZ should be straight-forward. But the existing EACCES mapping in there should probably switch to AccessDenied instead of the current PermissionDenied. Maybe?

I don't have "xterm256-color" on my system in the same place, and my terminfo files are not "immutable", so if I run the example (pointing at my local "xterm-256color") I get an EACCES error (mapped to PermissionDenied). If you've got a system with immutable files on it, there are probably a bunch of other Zig syscall wrappers that are missing errno mappings (assuming Linux is at all consistent about the errno in this case ...).

[giann]

I see.
I'm on macOS so maybe that's why the permission and maybe the errno is different.