Directory walking fails on linux but not on mac?

[frozen wraith]

The last line of this code panics (not errors, but panics) in a github action (ubuntu-latest):

var dir = std.fs.cwd().openDir(folder, .{}) catch |e| {
    log.warn("Resource loader failed opening {s}. Error: {any}", .{ folder, e });
    return false;
};
defer dir.close();
var i = dir.iterate();
while (i.next() catch return error.ReadRepoFileFailed) |file| {

Why would it fully just panic? Shouldnt it return an error if I was doing somthing wrong? Wat am I misunderstanding!

/home/runner/work/_temp/2a9c62fe/zig-x86_64-linux-0.14.1/lib/std/fs/Dir.zig:361:40: 0x110416b in nextLinux (test)
                        posix.lseek_SET(self.dir.fd, 0) catch unreachable; // EBADF here likely means that the Dir was not opened with iteration permissions
                                       ^
/home/runner/work/_temp/2a9c62fe/zig-x86_64-linux-0.14.1/lib/std/fs/Dir.zig:345:34: 0x10fef07 in next (test)
            return self.nextLinux() catch |err| switch (err) {
                                 ^
/home/runner/work/resources/resources/src/resources.zig:336:22: 0x10fd2b8 in load_directory (test)
        while (i.next() catch return error.ReadRepoFileFailed) |file| {

[placid cipher]

try var dir = std.fs.cwd().openDir(folder, .{ .iterate = true }) catch ...

[frozen wraith]

Thanks, yes, I am just trying this now....

Fixed, thanks. I wonder if this is a bug. I am not sure why it would panic (and only on linux) if you forget to add a flag.

The stack trace is helpful though.

thread 2095 panic: reached unreachable code
/home/runner/work/_temp/2a9c62fe-deba-4d80-b1e6-66f14f71e4b9/zig-x86_64-linux-0.14.1/lib/std/posix.zig:5247:18: 0x1107eb2 in lseek_SET (test)
        .BADF => unreachable, // always a race condition

/home/runner/work/_temp/2a9c62fe-deba-4d80-b1e6-66f14f71e4b9/zig-x86_64-linux-0.14.1/lib/std/fs/Dir.zig:361:40: 0x110416b in nextLinux (test)
                        posix.lseek_SET(self.dir.fd, 0) catch unreachable; // EBADF here likely means that the Dir was not opened with iteration permissions

[placid cipher]

These std functions are implemented in a way, that they do unreachable if the error is in the code that uses std and they return an error if the error is caused by factors not in your code (e.g. when you don't have permission to a file).

[ionic gyro]

The docs of openDir say:

The directory cannot be iterated unless the iterate option is set to true.
I guess the reason is implementation details and maybe on mac it was not worth adding an additional check as it is working without the flag.

Unfortunately Dir.iterate() and Dir.walk() do not mention that the flag is needed.

[frozen wraith]

Thats helpful. Thanks.

I guess it feels like a bug if the behaviour is not consistent across platforms. If the iterator setting is required, it feels like it should be possible to notice that before the code gets all the way to the posix call.

[ionic gyro]

I agree, it should be an error on all platforms; but maybe the mac implementation does not save the settings and does not use them anywhere else, in that case I don't think the consistency is worth it and a warning in documentation would be enough.
Also note that some differences between platforms will always exist. For example, a platform could not support iteration for some reason and return an error no matter what.

[frozen wraith]

Yea. Its not a huge deal, the stack trace has a helpful explanation. I guess I just assumed that the api should be consistent. I need to start doing github actions for my personal projects so that non Mac people dont have to encounter the weird cross platform things.

[placid cipher]

The reason in the specific case is that without .iterate = true, the dir will be opened with the O_PATH flag, which is a linux specific flag that disallows most operations of the file descriptor of the dir. On mac this flag just doesn't exist, so you get fd with all operations.