I have a working implementation on current Wasmtime main for two related filesystem lifecycle boundaries that came up in an embedding use case.
The first is active filesystem work: native work can outlive the initiating future, resource, or Store, so an embedder-provided operation owner needs to follow the actual native work.
The second is native handle lifetime: an idle descriptor can still retain access to temporary/backing content even when no operation is active. That ownership therefore needs to follow the underlying native File/Dir independently of operation admission.
The implementation keeps those separate:
FilesystemOperation::new(value)
WasiFilesystemCtx::set_operation_hook(...)
WasiCtxBuilder::filesystem_operation_hook(...)
FilesystemHandle::new(file, owner)
FilesystemHandle::try_clone(...)
File/Dir share Arc<FilesystemHandle>, so native workers and second-descriptor operations automatically retain the appropriate handle owner. Child opens inherit it inside the native worker. push_descriptor handles callback provenance for embedder-created descriptors.
One case that convinced me the handle owner needs to live with the native handle itself is is_same_object: work is admitted through descriptor A while the worker also carries descriptor B’s native handle. B’s descriptor/callback can disappear while that worker still uses B. link_at and rename_at have the same shape.
The patch is working and locally validated against current main; I’ve also tested it from the downstream consumer. The main compatibility cost is that the public File.file / Dir.dir types change from Arc<std::fs::File> to Arc<FilesystemHandle>.
Before I open a PR, does this separation between an operation owner and an opaque native filesystem-handle owner fit where you’d want these lifecycle boundaries represented, particularly given those existing public raw File/Dir fields?
Candidate branch:
https://github.com/wetware/wasmtime/tree/lthibault/filesystem-lifecycle-v2
Exact commit:
https://github.com/wetware/wasmtime/commit/4c825b2e83cf23854e2f67d56e8e955e431d975d
Bump. Please let me know if there's anything else that's needed to move the discussion forward. Thx!
Last updated: Oct 31 2026 at 23:03 UTC