Question for directory_seek test
harry900831 opened this issue · 3 comments
According to this test, it seems that using fd_seek
on a directory is forbidden, though I can call lseek
on a directory fd in POSIX. Also, we shouldn't set the fd_seek bits on a directory despite explicitly setting it in path_open
.
I can't find any document or discussion related to this behavior which is unsetting the rights that are explicitly set in path_open
for the directory.
My question is:
- I'm wondering whether unsetting the rights is a good choice compare to returning
ISDIR
error while using the function. - Which right should be disabled if the file is a directory?
I believe this should be documented.
It seems that the rights system may be removed. Getting a workaround to pass the test is what I intended to do.
A related issue in wasi-filesystem: WebAssembly/wasi-filesystem#103
Thanks in advance!
Calling lseek
on a directory opened with fdopendir
invokes undefined behavior, according to POSIX "Upon successful return from fdopendir(), the file descriptor is under the control of the system, and if any attempt is made [...] to modify the state of the associated description, other than by means of closedir(), readdir(), readdir_r(), rewinddir(), or seekdir(), the behavior is undefined."
WASI doesn't have an explicit fdopendir
function, but a typical implementation would use fdopendir
internally. This makes it tricky to implement the host side of fd_seek
on directories in a meaningful way, and tricky for guest code to use fd_seek
on directories in a meaningful way. It may be possible to figure out some way to do it, however it'd take some work, and it doesn't seem likely that much existing code would benefit, because POSIX's own rules imply that user code shouldn't be using lseek
in this way.
I propose we instead document that fd_seek
simply fails when used on directory handles.
Thank you for your reply! I agree that fd_seek
should fail when it's used on directory handles.
My concern is that the expected behavior should be documented, otherwise it is just an implementation choice for runtime.
It seems that wasmtime may unset the fd_seek rights bit only while using wasi::OFLAGS_DIRECTORY
at the same time, which I believe is an implementation choice.
I propose the rights check for this test should be removed. Moreover, which wasi function may fail on directory handles should be documented to make this test reasonable.
Is there any update on this issue?
Thanks.