Ability to construct virtual `Dir`s to mount files and subdirectories into

[primoly]

Specifically with the option for those files/dirs to just be paths that don’t need to be opened when mounted. Note: When I say “mount” here this would only be internal to the Dir struct and not actual mounts on the underling filesystem. Similar to Pool’s insert methods.

Would particularly be interesting to create a root Dir which would just be / on Unix but on Windows a folder exposing all drive letters as subfolders. I understand that this specific use case may be controversial, as it seems to go against the spirit of this crate. But I believe the opposite to be true: The great thing about this API is that it doesn’t just have one or two layers (as more basic security systems), but arbitrarily many as each Dir recursively can be used to create narrower views. So I don’t think one global directory as the base to craft more specialised capabilities would inherently be a bad idea.

Based originally on thinking in bytecodealliance/wasmtime#8552 to solve the problem of Windows (unlike Unix) not having a single root folder but essentially one for each volume, which makes cap-std difficult to use in some contexts.

I apologise should what I propose already be possible, in a quick look into the docs I haven’t figured out a way to do this.

[whitequark]

This would be fantastic! Another desire (which is, I think, more for wasi-libc than cap-std) is to have support for backslashes in paths, for the same reason. Right now all Windows paths have to be converted to use forward slashes, which doesn't work in/with UNC paths, and can be difficult to do when third-party tools are involved.

[sunfishcode]

Such a Dir would not be able to implement from_std_file, as_raw_handle, and similar things in the current Dir API. Would it make sense for the functionality of a "root of the drive letters" to be implemented in Wasmtime, rather than in cap-std here?

Also, as a personal limitation, I don't see a path by which I will ever be able to understand how Windows paths work (I have already read every document about it in Microsoft's documentation). But if someone who can speak authoritatively on the subject can submit a PR, or tell me what to do in specific enough steps that I can follow them without really understanding, I'll do it.

[whitequark]

But if someone who can speak authoritatively on the subject can submit a PR, or tell me what to do in specific enough steps that I can follow them without really understanding, I'll do it.

I believe that I'm that someone--I've dealt with Windows paths extensively and I think I have a decent enough grasp of them, aside from some things not relevant to Wasmtime (like the NT object manager paths). I'm also happy to give you step-by-step instructions for the use of the APIs with all the preconditions and postconditions I know of listed. But I think I'm missing wasmtime-side context on this.

[ChrisDenton]

I hesitate to suggest it but the way to do this "properly" would be to use NtOpenDirectoryObject to open the object manager directory \?? with DIRECTORY_TRAVERSE access. This can then be used as the root directory in calls to NtOpenFile or NtCreateFile (or anything else taking OBJECT_ATTRIBUTES).

[whitequark]

That would work!