ln: add WASI support via symlink_path#11713
ln: add WASI support via symlink_path#11713DePasqualeOrg wants to merge 3 commits intouutils:mainfrom
Conversation
On wasm32-wasip1, std::os::unix::fs::symlink is not available, but WASI preview 1 provides path_symlink which Rust exposes as std::os::wasi::fs::symlink_path. Import it under the symlink alias so the existing call site works without changes. Follows the same pattern as cp.rs for enabling wasi_ext.
|
GNU testsuite comparison: |
|
|
I added a new commit to address the CI failures. The WASI CI uses stable Rust, but |
|
GNU testsuite comparison: |
DePasqualeOrg
force-pushed
the
wasi-ln-symlink
branch
from
fdc57ce to
ea6e1d0
Compare
|
GNU testsuite comparison: |
src/uu/ln/src/ln.rs
Outdated
| pub fn symlink<P1: AsRef<Path>, P2: AsRef<Path>>(src: P1, dst: P2) -> io::Result<()> { | ||
| use std::os::wasi::ffi::OsStrExt; | ||
|
|
||
| let src_c = CString::new(src.as_ref().as_os_str().as_bytes()) |
There was a problem hiding this comment.
can we use libc or rustix instead?
i really would like to avoid CString
|
could you please add a test? |
|
still need a test :) |
|
It's now using rustix instead. It looks like the existing integration tests cover symlink creation, but CI has |
|
we do run it here : |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@oech3 please don't use this PR for this discussion |
|
GNU testsuite comparison: |
|
I have enabled integration tests for WASI in #11717. I suggest that that PR be reviewed first, and after it's merged I can enable symlink tests in this PR. |
3 participants
This PR replaces the error-returning WASI stub with a real symlink implementation using
std::os::wasi::fs::symlink_path.Changes
std::os::wasi::fs::symlink_path as symlinkalongside the existing unix and windows symlink importsfn symlinkstub that returnedio::ErrorKind::Unsupported#![cfg_attr(target_os = "wasi", feature(wasi_ext))]for access tostd::os::wasi::fsLimitations
Relative symlink targets work. Absolute symlink targets (e.g.,
ln -s /tmp/foo link) are rejected by WASI runtimes due to capability-based sandboxing — this is a platform constraint, not a code limitation.Build requirements
Rust nightly (for
std::os::wasi::fs, gated withfeature(wasi_ext)).Testing
Verified working on Wasmer and Wasmtime with relative symlink targets.