Change:
Currently, Unix and Windows expose and correspondingly, which both simply accept source and destination by . However, the currently exposed WASI method - is lower-level and requires user to have a file descriptor of the preopened directory in addition to the file paths: This is different from all other methods and not ideal, because it requires calling even more lower-level methods to find and retrieve that preopened directory by file path first, and libpreopen isn't exposed to users, so they have to do this all manually. Moreover, the codebase already contains a higher-level helper for symlinking files by path and hiding these syscall details, it's just not currently exposed to users: If this is not too late in terms of backwards compatibility, it would be better to remove the currently exposed low-level syscall and expose this helper instead, so that users could work on paths more easily like they do on other platforms. Alternatively, it's necessary to at least expose helpers for retrieving the preopen directory from a file path, as otherwise it's not possible to construct symlinks from userland without invoking raw syscalls.
I'm sorry, but since it's been half a year... friendly ping? do you think we can expose that symlink helper?
I'm not really sure what this is proposing myself, so I'm not sure? What is a "symlink helper"?
The second function referenced above - basically a way to create a symlink with just source and dest paths, like you can on other platforms with or . Right now the exposed variant of that function requires not only paths, but also knowing a file descriptor of the preopened dir, making it impossible to use from safe code (since preopened dirs are managed internally by WASI libc).
I would personally think that a better option would be to expose in one way or another for wasi since that seems more appropriate for a -module-functionality.
I totally agree it makes sense for module in general, but it seems to be more of an implementation detail in this case. The often provide OS-specific extensions to regular methods, not necessarily low-level ones. Symlink, in particular, seems like something that should work as straightforward as, say, , or any other universal APIs. That is, I think all those OS-specific implementations should still follow the deprecated universal API from older Rust times -  - with same ease of use, just under different namespaces.
I'm not exactly the gatekeeper of the wasm module or anything, I'm basically just saying that I would not personally pursue adding this method to the standard library. If you'd like to do so you can certainly do that, however.
I've mostly asked you because you authored that helper function that I'd love to see exposed. I think it's useful for ease of use and consistency with other platforms. I'm happy to make a PR myself if it would be accepted.
Looks like people are already misusing the currently exposed API for symlinks - since there is no way to use it right :(
Given above, finally got back to this and made a PR to fix it:

Discussion:
.fd() .symlink(osstr2str(old_path.as_ref().as_ref())?, osstr2str(new_path.as_ref().as_ref())?) } <ins> /// Create a symbolic link. /// /// This is a convenience API similar to [`std::os::unix::fs::symlink`] and /// [`std::os::windows::fs::symlink_file`] and [`symlink_dir`](std::os::windows::fs::symlink_dir). pub fn symlink_path<P: AsRef<Path>, U: AsRef<Path>>(old_path: P, new_path: U) -> io::Result<()> { crate::sys::fs::symlink(old_path.as_ref(), new_path.as_ref()) } </ins>