Repository navigation
std::fs::hard_link doesn't work on WASI #82277
Description
I tried this code:
fn main() {
std::fs::hard_link("/a", "/b").unwrap();
}I compiled it with --target wasm32-wasi and executed with latest Wasmtime 0.23.0 with wasmtime --mapdir=/::. where the current directory contains valid file a.
I expected to see this happen:
A hard link b is created that points to a.
Instead, this happened:
It fails with an error:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 28, kind: InvalidInput, message: "Invalid argument" }', temp.rs:2:36
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: failed to run main module `temp.wasm`
Caused by:
0: failed to invoke command default
1: wasm trap: unreachable
wasm backtrace:
0: 0x7b4c - <unknown>!__rust_start_panic
1: 0x75e5 - <unknown>!rust_panic
2: 0x71bd - <unknown>!std::panicking::rust_panic_with_hook::hb9189a2ae1f00dd6
3: 0x6928 - <unknown>!std::panicking::begin_panic_handler::{{closure}}::ha38be87363679287
4: 0x6869 - <unknown>!std::sys_common::backtrace::__rust_end_short_backtrace::h955bbbeea72dc4a0
5: 0x7061 - <unknown>!rust_begin_unwind
6: 0xd0a6 - <unknown>!core::panicking::panic_fmt::h904ce09f3cb14707
7: 0xdbcc - <unknown>!core::option::expect_none_failed::ha29c9c4296a18e58
8: 0xfee - <unknown>!core::result::Result<T,E>::unwrap::hcf72e0af954224e8
9: 0x9b7 - <unknown>!temp::main::hdc57b3c35eac1777
10: 0xac2 - <unknown>!core::ops::function::FnOnce::call_once::h9d9b1f2044973e11
11: 0x8ac - <unknown>!std::sys_common::backtrace::__rust_begin_short_backtrace::h0d198c55a40ffd2e
12: 0xdf2 - <unknown>!std::rt::lang_start::{{closure}}::he287b5106de2dbae
13: 0x76f6 - <unknown>!std::rt::lang_start_internal::h81003f47a7b429a5
14: 0xdc6 - <unknown>!std::rt::lang_start::h75812a9706ce1699
15: 0x9e8 - <unknown>!__original_main
16: 0x3f9 - <unknown>!_start
note: run with `WASMTIME_BACKTRACE_DETAILS=1` environment variable to display more information
Meta
rustc --version --verbose:
rustc 1.49.0 (e1884a8e3 2020-12-29)
binary: rustc
commit-hash: e1884a8e3c3e813aada8254edfa120e85bf5ffca
commit-date: 2020-12-29
host: x86_64-unknown-linux-gnu
release: 1.49.0
wasmtime --version:
wasmtime 0.23.0
Equivalent C code
I've also tried to compile an equivalent C code to exclude possibility of a bug in Wasmtime itself:
#include <unistd.h>
int main() {
return link("/a", "/b");
}
When this is compiled with WASI SDK clang --target=wasm32-wasi and executed with the same command in Wasmtime, it successfully creates the hardlink.
Activity
osa1 commentedon Feb 19, 2021
Generated code for C and Rust versions of this program are wildly different, so I think C version running fine does not rule out the possibility that this could be a wasmtime bug.
I'm unable to build WASI-enabled stage1 compiler so I tried with
nightly 152f66092 2021-02-17. If I run with wasmtimemainbranch I get the original error as reported.If I run with wasmer (
wasmer run test_rust.wasm --mapdir "/::.") the process exits with 0, without printing any errors, but I don't see the linked file.If I run with my own interpreter the process exits with 0 and I see the linked file.
RReverser commentedon Feb 19, 2021
It's probably worth comparing the arguments and the result of
wasi.path_linkcall, which both should invoke under the hood.RReverser commentedon Feb 19, 2021
Ah, forgot to mention - I also tried to execute with Wasmer, but it silently doesn't do anything on both outputs, so I think that's a separate issue.
RReverser commentedon Feb 19, 2021
Hmm, okay, I tried to execute both with Node.js WASI support, and it does work. So perhaps it is a Wasmtime issue after all.
RReverser commentedon Feb 19, 2021
Oh... and it doesn't fail on Wasmtime 0.22, but fails on 0.23. Closing here.
RReverser commentedon Feb 19, 2021
UPD: as mentioned on the linked Wasmtime issue, turns out this is partially a Rust issue after all and it already has a pending fix in #81984.