pathchk: empty path operand is accepted under WASI (wasmtime)

[eduardomourar]

Summary

Under the WASI runner (wasmtime, wasip1), pathchk "" with a preopened succeeds instead of failing with "No such file or directory". This diverges from the behavior on other platforms and from GNU.

Details

pathchk decides whether to reject an empty operand by asking the platform via fs::symlink_metadata. On Unix hosts symlink_metadata("") returns ENOENT, so the empty path is rejected. Under WASI with a preopen, it returns Ok, so the operand is accepted and no error is produced.

Reproduction

wasmtime --dir=.::/ pathchk.wasm ""

Expected: pathchk: '': No such file or directory and a non-zero exit. Actual (WASI): succeeds with no output.

Impact

The empty-path assertions in test_default_mode cannot run under the WASI runner and are gated out there. The rest of the test still runs.

System details

Rust version: 1.98.1
Target: wasm32-wasip1
wasmtime: 47.0.3

[oech3]

Is it able to fix it at std::fs side?

[thomas-btst]

Hello, I wasn't able to reproduce the issue on the latest main branch.

~/projects/coreutils $ cargo build --target wasm32-wasip1 -p uu_pathchk --bin pathchk
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.50s

~/projects/coreutils $ wasmtime run ./target/wasm32-wasip1/debug/pathchk.wasm ""; echo $?
pathchk.wasm: '': No such file or directory
1

~/projects/coreutils $ git log -5 --oneline
cef136470 (HEAD -> main, origin/main, origin/HEAD) Update dawidd6/action-download-artifact action to v27

[eduardomourar]

@thomas-btst, you are right. I updated the repro command to include the preopen (which is what we have in our integration tests). It does not have the expected outcome with the --dir argument but it works correctly without it.

[eduardomourar]

Is it able to fix it at std::fs side?

No, we will would not be able to fix it in Rust standard library, but we could fix it in the wasi-libc (already raised the issue there). For now, we will need a workaround in coreutils.