wasm32-wasi: opening/reading a directory as a file surfaces EBADF, not IsADirectory

[eduardomourar]

I tried this code:

use std::fs::File;
use std::io::Read;

fn main() {
    let mut f = File::open("/some/dir").unwrap(); // succeeds on WASI
    let mut buf = [0u8; 16];
    println!("{:?}", f.read(&mut buf));
}

I expected to see this happen: an Err with kind() == IsADirectory, matching Unix (EISDIR) and Windows.

Instead, this happened: Err with kind() == Uncategorized, raw_os_error() == Some(8) (EBADF). WASI defers the directory check from open to the first read, and reports it as EBADF rather than EISDIR, so it falls through every arm of decode_error_kind (shared between unix/wasi since #143189) to Uncategorized.

Reproduced on both wasm32-wasip1 and wasm32-wasip2 via wasmtime 45.

Note EBADF is ambiguous (a real closed-fd error must not become IsADirectory), so this likely cannot be a decode_error_kind table entry — it probably needs to be handled contextually in the WASI open/File::open path in sys/fs/unix.rs, where std already knows a directory was being opened as a file. See uutils/coreutils#13625 for a userland workaround (wasi_normalize_open_error) doing exactly this at the call site.

Meta

rustc --version --verbose:

rustc 1.99.0-nightly (ad3d0bc14 2026-07-31)

[bjorn3]

For wasip1 it should be possible for the wasi runtime to directly return EISDIR. For wasip2 I think wasi-libc should be changed.

[eduardomourar]

I agree with you for wasip2, but I don't think it rules out also fixing this in std.

On POSIX alignment: this split (open succeeds, read fails) already matches the spec, not just WASI convention. open() only defines EISDIR for O_WRONLY/O_RDWR/O_CREAT-without-O_DIRECTORY — a read-only open of a directory must succeed. The check is deferred to read(), which defines EISDIR directly: "The fildes argument refers to a directory and the implementation does not allow the directory to be read using read() or pread()." So the only bug is which errno read() reports, not that the check happens at read time.

Agreed wasi-libc is the better long-term fix for wasip2 specifically — it sits below every C-ABI language targeting wasm32-wasip2 (C, C++, Zig, Rust), so a fix there benefits all of them at once. But that doesn't cover wasip1, where the fix has to be per-runtime (wasmtime, WAMR, wazero, …) since preview1 has no shared libc translation layer — each runtime returns its own path_open/fd_read errno directly. A wasmtime fix wouldn't help other preview1 engines.

Given that, I think the contextual fix in sys/fs/unix.rs's wasi-gated open path is still worth landing in std: it's POSIX-consistent (the same kind of raw-errno reconciliation decode_error_kind already does elsewhere), and it fixes every existing wasi runtime binary on the next rustc release rather than waiting on multiple runtime/libc projects to ship and propagate through wasi-sdk. Not either/or — the runtime and libc fixes are still worth doing, but std shouldn't block on them.

[bjorn3]

How would libstd know when to return EISDIR vs pass through the EBADF unchanged? libstd doesn't know that the fd refers to a directory. EBADF can also occur when an fd refers to a file that is not opened with read cq write access when doing a read or write.

[eduardomourar]

Fair. A remap is wrong, and I'll admit our own userland workaround (uucore's wasi_normalize_open_error) has that exact flaw: it treats any EBADF as EISDIR unconditionally.

But std doesn't need to guess from context, it can ask. File::file_attr() in sys/fs/unix.rs already calls fstat64(fd, ...) generically, and that's not gated out for wasi: wasi-libc's fstat() is a normal libc wrapper around fd_filestat_get, so it already works today. On a wasi read returning raw EBADF, std could call the same fstat/file_attr path on that fd and only remap to IsADirectory if the reported file type is a directory — otherwise pass the original error through unchanged. Costs one syscall, only on the already-erroring path.