Add PipeNotAvailable error

[JustinBraben]

Should fix #21312

The unexpected error.Unexpected NTSTATUS=0xc00000ac is .PIPE_NOT_AVAILABLE in windows. So this PR adds handling for it.
I believe it is similar to PipeBusy, please correct me if I am mistaken.

The stat.zig program should now exit successfully.

[squeek502]

The description of PIPE_NOT_AVAILABLE is

An instance of a named pipe cannot be found in the listening state.

From what I can tell, the most similar Linux error return for open is ENXIO:

ENXIO  O_NONBLOCK | O_WRONLY is set, the named file is a FIFO,
       and no process has the FIFO open for reading.

I say this because attempting to open a pipe that actually doesn't exist on Windows returns OBJECT_NAME_NOT_FOUND, which gets translated into error.FileNotFound.

So, my initial thoughts:

• Might make sense to map NXIO and PIPE_NOT_AVAILABLE to the same error (at least for the cross-platform std.fs API)
  • Note: we don't currently handle NXIO as a possible error in std.posix.open/openat, and NXIO can be returned in other situations than precisely this one (from the Linux man page linked above, "The file is a device special file and no corresponding device exists." and "The file is a UNIX domain socket."). EDIT: Here's a link to the POSIX open spec, it has slightly different NXIO docs.
• Is there something in the parameters we're giving to NtCreateFile when statFileing that is causing this error return? It doesn't seem like statFile should care about whether or not the pipe is in the listening state, as we're not trying to open it for writing (right?).
  • This is unrelated to how we should deal with PIPE_NOT_AVAILABLE, but my initial reaction is that the specific reproduction in dir.statFile on windows named pipe sometimes produces unexpectedStatus #21312 shouldn't be triggering this error at all

EDIT: Nothing seems off about the NtCreateFile parameters (DesiredAccess is FILE_GENERIC_READ | SYNCHRONIZE, ShareAccess is FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, CreateDisposition is FILE_OPEN, and CreateOptions is FILE_NON_DIRECTORY_FILE | FILE_SYNCHRONOUS_IO_NONALERT). All my attempts at changing those parameters didn't allow me to avoid the PIPE_NOT_AVAILABLE error. It's interesting that NtQueryDirectoryFile can return information about these pipes (since their info is returned during iteration), but we can't seem to get a handle to them?

[JustinBraben]

@squeek502 Could it be because of the next() function of Dir.Iterator for windows?

https://github.com/ziglang/zig/blob/560d6b99d5be8e906b7d8d70a2b2e1f1d4da4f89/lib/std/fs/Dir.zig#L472C17-L481C19

const kind: Entry.Kind = blk: {
    const attrs = dir_info.FileAttributes;
    if (attrs & w.FILE_ATTRIBUTE_DIRECTORY != 0) break :blk .directory;
    if (attrs & w.FILE_ATTRIBUTE_REPARSE_POINT != 0) break :blk .sym_link;
    break :blk .file;
};
return Entry{
    .name = name_wtf8,
    .kind = kind,
};

For windows the kind can never actually be set to a .named_pipe in this Iterator, which I think should be possible.

[squeek502]

For windows the kind can never actually be set to a .named_pipe in this Iterator, which I think should be possible.

You're right that Windows can never return .named_pipe as the kind, but that is a separate issue.

My last response was a bit convoluted, so here's some more actionable feedback:

• The changes in this PR seem good as-is
• If we want to future proof/choose a better name for the error, thinking about what NXIO of the POSIX/Linux open syscall should be mapped to would probably make the most sense, since I think it's roughly equivalent
• I'm not sure why NtCreateFile during statFile is failing in the specific reproduction in dir.statFile on windows named pipe sometimes produces unexpectedStatus #21312, but that can be investigated in a follow-up issue, as it's ultimately unrelated to this PR

[JustinBraben]

Some ideas: PipeNotUnavailable, FIFOUnavailable, PipeNotReadable, FIFONotReadable ?

[squeek502]

In #21983, NXIO in openat was mapped to error.NoDevice, so that's another option here as well.

[JustinBraben]

I'll update this to be error.NoDevice then.

[alexrp]

LGTM; will wait for @squeek502 to sign off as well before merging.