Suggestion: no-op set_permissions for WASI

[RReverser]

Currently, WASI target implements retrieving permissions with a no-op and just returning a default value:

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

Lines 75 to 78 in a237641

	pub fn perm(&self) -> FilePermissions {
	// not currently implemented in wasi yet
	FilePermissions { readonly: false }
	}

However, the corresponding setter method is instead implemented by returning an error:

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

Lines 424 to 428 in a237641

	pub fn set_permissions(&self, _perm: FilePermissions) -> io::Result<()> {
	// Permissions haven't been fully figured out in wasi yet, so this is
	// likely temporary
	unsupported()
	}

This is unfortunate and breaks higher-level APIs like std::fs::copy which currently manages to successfully copy contents of file on a WASI target but then fails because the default implementation unconditionally calls set_permissions:

rust/src/libstd/sys_common/fs.rs

Lines 19 to 21 in d8bdb3f

	let ret = io::copy(&mut reader, &mut writer)?;
	fs::set_permissions(to, perm)?;
	Ok(ret)

To both fix such issues and from a semantic point of view, too, it seems it would be better to mirror the behaviour of the getter (permissions method) and just perform no-op in set_permissions on a WASI target, at least until WASI specification decides to extend support and add real permissions model.

Would the team be open to this?

[RReverser]

Ping @alexcrichton @fitzgen?

[alexcrichton]

I would personally prefer to ensure that wasi-libc for C stays in sync with Rust's libstd, so I think that this is probably best a question for the wasi group as opposed to Rust's libstd specifically.

[RReverser]

I see; WASI SDK conditionally excludes chmod for WASI target during compilation, and I suppose that's what Rust wants to avoid and instead simulates with a runtime error. Fair enough.

In that case, would you be open to adding a specific implementation of std::fs::copy for WASI target that just uses std::io::copy but doesn't set permissions? There is no direct analogue for it in the wasi-libc anyway, and it would solve fix specific API function not working at all, without changing the rest.