Expose WASI symlink helper

[RReverser]

Currently, Unix and Windows expose std::os::unix::symlink and std::os::windows::fs::symlink_file correspondingly, which both simply accept source and destination by Path.

However, the currently exposed WASI method - std::os::wasi::fs::symlink is lower-level and requires user to have a file descriptor of the preopened directory in addition to the file paths:

rust/src/libstd/sys/wasi/ext/fs.rs

Lines 397 to 405 in 8a79d08

	pub fn symlink<P: AsRef<Path>, U: AsRef<Path>>(
	old_path: P,
	fd: &File,
	new_path: U,
	) -> io::Result<()> {
	fd.as_inner()
	.fd()
	.symlink(osstr2str(old_path.as_ref().as_ref())?, osstr2str(new_path.as_ref().as_ref())?)
	}

This is different from all other fs 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:

rust/src/libstd/sys/wasi/fs.rs

Lines 538 to 541 in a605441

	pub fn symlink(src: &Path, dst: &Path) -> io::Result<()> {
	let (dst, dst_file) = open_parent(dst)?;
	dst.symlink(osstr2str(src.as_ref())?, osstr2str(dst_file.as_ref())?)
	}

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.

[RReverser]

I'm sorry, but since it's been half a year... friendly ping? @alexcrichton do you think we can expose that symlink helper?

[alexcrichton]

I'm not really sure what this is proposing myself, so I'm not sure? What is a "symlink helper"?

[RReverser]

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 std::os::unix::fs::symlink or std::os::windows::symlink_file.

Right now the exposedstd::os::wasi::fs::symlink 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).

[alexcrichton]

I would personally think that a better option would be to expose open_parent in one way or another for wasi since that seems more appropriate for a sys-module-functionality.

[RReverser]

I totally agree it makes sense for sys module in general, but it seems to be more of an implementation detail in this case.

The std::os::(somename)::fs often provide OS-specific extensions to regular fs methods, not necessarily low-level ones. Symlink, in particular, seems like something that should work as straightforward as, say, File::open, std::fs::copy 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 - std::fs::soft_link - with same ease of use, just under different namespaces.

[alexcrichton]

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.

[RReverser]

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.

[RReverser]

Looks like people are already misusing the currently exposed API for symlinks - since there is no way to use it right :( vitiral/path_abs#50 (comment)

[RReverser]

Given above, finally got back to this and made a PR to fix it: #81542