How should .. paths be resolved?

[sunfishcode]

On POSIX, path resolution is performed one component at a time, and .. is resolved only after resolving all components that came before it. Opening a path such as nonexistent/.. fails, because opening nonexistent first fails.

On Windows, path resolution has an up-front parsing step which resolves ... On nonexistent/.., it's resolved to . first, so opening it succeeds.

Should we require Windows implementations to emulate POSIX semantics here, or say that whether .. is resolved up front or on the fly is nondeterministic?

[MaulingMonkey]

I'd lean towards allowing it to be nondeterministic.

Multiple syscalls to emulate POSIX semantics sounds slow - especially in the case of network attached storage - and perhaps inconsistently implemented as a result, even on supposedly POSIX systems (if, for example, they might be talking to non-POSIX systems over odd network mounts or similar.)

[pchickey]

One way out of this is to put the burden of resolving . and .. in paths to userland, and not permitting either to be used in paths passed to WASI.

[MaulingMonkey]

That would have the effect of allowing self-imposed unveil-lite like behavior, by simply closing all FDs to root/parent directories outside of the chroot.

[sunfishcode]

WASI filesystem allows applications to voluntarily sandbox themselves by closing fds to directories they don't need, or even opening subdirectories and closing the parent fds.

My sense here is that this is similar to the issues with case sensitivity. We aren't going to achieve full filesystem determinism without drastic costs. And there systems which do both eager and on-demand .. resolution in wide use, and emulating either would add overhead for all use cases just to serve the very uncommon cases where the difference actually matters. So my sense is, we should just let host platforms resolve .. how they see fit.

[codefromthecrypt]

I don't think having the host resolve ".." will work. In current practice, the current working directory is tracked in guest code, not host code. Lacking any ability to hook on cd/chdir I think relative lookups must be out of scope from perspective of the host.