Add WASI platform support #144
Conversation
src/operations.cpp
Outdated
| @@ -1564,7 +1566,9 @@ void create_symlink(const path& to, const path& from, error_code* ec) | |||
| BOOST_FILESYSTEM_DECL | |||
| path current_path(error_code* ec) | |||
| { | |||
| # ifdef BOOST_POSIX_API | |||
| # if defined(__wasm) | |||
| return "."; | |||
There was a problem hiding this comment.
This is not right, current_path must return an absolute path (see C++20 [fs.op.current.path]). For example, copy implementation relies on that, and probably not only that.
If the platform does not support current_path, it should fail with BOOST_ERROR_NOT_SUPPORTED (ENOSYS), but then I'm not sure how useful the rest of the library would be as it is used in implementation of quite a few operations.
There was a problem hiding this comment.
As an alternative, you could assume that the current path is always the root directory. I'm not sure how valid is that in WASI (i.e. is equivalent(".", "/") == true).
There was a problem hiding this comment.
Also, see if there is a way to obtain path from a file descriptor or from the result of stat on WASI.
There was a problem hiding this comment.
Understood. I'll check whether this assumption holds (the precise WASI semantics around . are not entirely clear to me) and see what can be done.
There was a problem hiding this comment.
Also, see if there is a way to obtain path from a file descriptor or from the result of
staton WASI.
That's what the fd_prestat_dir_name syscall is for.
There was a problem hiding this comment.
Can you use it to obtain the full path to '.'?
There was a problem hiding this comment.
If the platform does not support
current_path, it should fail withBOOST_ERROR_NOT_SUPPORTED(ENOSYS), but then I'm not sure how useful the rest of the library would be as it is used in implementation of quite a few operations.
I've changed the code to do that. It turns out that the application I'm porting is only using boost::filesystem::path, so it's still useful for that. Failing with BOOST_ERROR_NOT_SUPPORTED seems to be a safe choice that can be always revisited later, perhaps with input from WASI folks.
There was a problem hiding this comment.
Can you use it to obtain the full path to '.'?
No. There is no concept of an "absolute path" in WASI, since it eliminates ambient authority and uses capabilities for everything; the /<something> directory, . directory, and .. directory behave effectively like separate mounts, akin to the way . and .. work on FAT, if you've seen that. There might not be any other name by which the application can access ..
WASI is really designed to use exclusively openat, and it only provides open as a shim over openat to aid in porting applications. That's why the behavior is so strange.
WASI is a POSIX-like platform that has a few important differences: * There is no concept of a mutable current directory. * There is no concept of a file mode, and no `chmod` call. * There is no concept of a filesystem, and no `statfs` call. * There is no `readdir_r` call because there are no threads.
|
Thanks. |
|
Thanks for the quick review! |
WASI is a POSIX-like platform that has a few important differences:
.in the filesystem namespace that fulfills a similar role.chmodcall.statfscall.readdir_rcall because there are no threads.