preview2 component cannot access --wasi-fs preopens on v0.4.0 — get-directories returns no usable preopen, ENOENT on every path (capability enabled per #392, but component FS path unwired)

[avrabe]

Summary

On kilnd v0.4.0 (fresh build), a WASI Preview 2 component cannot read, list, or open any file under a --wasi-fs preopen — every operation fails with errno::noent (os error 44), for both relative and absolute paths and for read_dir. wasi:filesystem/preopens::get-directories is invoked but yields nothing the guest can use. wasmtime, given the same directory via --dir, reads and lists it fine.

This is the still-open remainder of #392: that issue's fix correctly enabled the filesystem capability (lib.rs:1421, on --wasi-fs), but the component path is still unwired beyond the capability gate — get-directories returns no usable preopen. Filing separately since #392 is closed and the gap has now survived the v0.3.5 → v0.4.0 bump.

Reproducer

Guest (rustc --target wasm32-wasip2 -O g.rs -o g.wasm):

use std::fs;
fn main(){
  match fs::read_to_string("inside.txt"){Ok(s)=>println!("READ:{}",s.trim()),Err(e)=>println!("READ_FAIL:{}",e)}
  match fs::read_dir("."){Ok(rd)=>{let n:Vec<_>=rd.filter_map(|e|e.ok().map(|e|e.file_name().to_string_lossy().into_owned())).collect();println!("DIR:{:?}",n)},Err(e)=>println!("DIR_FAIL:{}",e)}
}

mkdir sb && echo CANARY > sb/inside.txt
( cd sb && wasmtime run --dir .::. ../g.wasm )     # READ:CANARY   DIR:["inside.txt"]
( cd sb && kilnd --wasi --component --wasi-fs . ../g.wasm )
#   READ_FAIL:No such file or directory (os error 44)
#   DIR_FAIL:No such file or directory (os error 44)

• Both --wasi-fs . and --wasi-fs <absolute> fail identically (so it is not a relative-vs-absolute mapping issue — even read_dir of the exact preopen path fails).
• RUST_LOG=trace shows - Filesystem paths: 1 and exactly one wasi:filesystem/preopens::get-directories call, after which the guest has no usable preopen.

Expected

kilnd --wasi --component --wasi-fs <dir> should let a preview2 component read/list files in <dir> (matching wasmtime --dir). If the component filesystem path is not yet implemented, --wasi-fs with --component should error loudly rather than silently returning ENOENT (per the repo's FAIL-LOUD rule).

Where to look

The capability is enabled and flows into the component provider (config.wasi_capabilities → init_wasi → ComponentModelProvider::new(capabilities)), and dispatcher.add_preopen(path) is called (lib.rs:571-573). But the component instance's get-directories still returns nothing usable — either the preopen is registered on a different dispatcher than the component instance queries, or the returned directory descriptor/path is not openable by the guest's WASI adapter. --fuel enforcement works on the same path (E03ED), so the component runtime itself is live.

Found via the pulseengine challenge harness (wasm32-wasip2 component FS differential vs wasmtime; fresh v0.4.0 build).

[avrabe]

Root-caused and partially fixed — thanks for the precise reproducer and trace, they made this fast.

Measured (your reproducer, single wasm32-wasip2 component): nested_component_instances = 0 (the InterComponentHandler override does not fire) and the queried dispatcher already held the preopen (preopens.len() = 1). So the wiring was fine — the defect was the canonical-ABI return encoding of get-directories: it wrote the list<tuple<descriptor,string>> entries at retptr+8 and path strings at retptr+20, but the return area for func() -> list<…> is only 8 bytes. The list was backed by memory the guest never allocated, so preview2 libc registered no usable preopen → ENOENT before any open-at, exactly as you saw.

Fixed in #406 (SR-37): get-directories now backs its return with cabi_realloc'd guest memory, mirroring the working get-arguments path. With it, the guest registers the . preopen and successfully open-at + stat's inside.txt (confirmed by trace) — where before it rejected the preopen outright.

Still open — this issue stays open. End-to-end read_to_string is now blocked one layer deeper: wasi:io/streams::[method]input-stream.blocking-read writes the returned list<u8> to a fixed unowned guest address (0x100000 + handle*0x10000), corrupting guest memory → the guest makes a bad indirect call → [Runtime][E07DA] Function not found in exports. Same unowned-memory class as get-directories, but harder: the read size is dynamic, so it needs on-demand cabi_realloc during dispatch rather than pre-allocation. Tracked as SR-38; v0.4.1 will cut once it lands so the release actually closes this end-to-end.

Trace so far: get-directories → open-at → metadata-hash → stat → read-via-stream → blocking-read → E07DA.

[avrabe]

Update — retested on the supported path (kiln HEAD 30373fee now rejects raw components with "lower it first with meld fuse … (RFC #46)", so the raw---component repro above is no longer the right invocation). Lowering the same wasip2 guest with meld fuse to a core module and running it under kilnd --wasi --wasi-fs . gives a concrete internal error, which pinpoints the root cause:

[WASI-TRACE] wasi:filesystem/preopens::get-directories args=[...]
[WASI-TRACE] wasi:filesystem/preopens::get-directories args=[...]
✗ Execution failed: [Runtime][E1B58] get-directories requires cabi_realloc pre-allocation (preopens_alloc not set)

So even on the RFC #46 core-module path, --wasi-fs is unusable: get-directories cannot return the preopen list because the required cabi_realloc pre-allocation (preopens_alloc) is not wired up. wasmtime reads the same directory fine. --fuel works on this path, so the runtime is otherwise live.

Repro:

meld fuse guest.component.wasm -o guest.core.wasm
( cd sandbox && kilnd --wasi --wasi-fs . ../guest.core.wasm )   # E1B58 preopens_alloc not set

Net: the capability is enabled (#392) but the preopen still can't be handed to the guest — now with a specific failure point (preopens_alloc / cabi_realloc for get-directories). This is the actionable version of #405.