vfs: add mount names and make the reserved root readable

[pipobscure]

Nothing identified a mounted virtual file system beyond its reserved mount point, which is an opaque implementation detail. A mount made with --vfs-mount in particular could not be told apart from the others, nor be found by the program it was mounted for.

Mount names

vfs.mount([name]) takes an optional name. A named mount can also be reached as path.join(os.devNull, 'vfs', name), a symbolic link to its mount point. A later mount under the same name takes the name over, and unmounting removes the names linking to that mount. Invalid names throw ERR_INVALID_ARG_VALUE. A name must be a single path segment other than . and .., and must not be spelled like a layer id, which is a non-negative integer in canonical decimal form. So 17 is reserved, while 07, -1 and NaN are valid names.

--vfs-mount and --vfs-load accept name=source and pass the name to vfs.mount(). Text before the first = is only a name if it has no path separator, so a path containing = can still be mounted by writing it as ./a=b. --vfs-load takes the prefix too, because a worker re-mounts every source without knowing which one --vfs-load contributed, and must split each value the same way.

The reserved root is a directory

While anything is mounted, ${os.devNull}/vfs is a read-only directory that plain node:fs code can read. It lists every mount point by its layer id, and every name as a symbolic link to that id:

fs.readdirSync(root);                  // [ '0', 'assets' ]
fs.readlinkSync(`${root}/assets`);     // '0'
fs.realpathSync(`${root}/assets`);     // '/dev/null/vfs/0'
fs.readFileSync(`${root}/assets/logo.svg`);

This came out of the discussion with @bakkot on #65748 and #66116 and a short chat to discuss the shape of it.

[nodejs-github-bot]

Review requested:

• @nodejs/config

[bakkot]

Thanks!

Some thoughts:

• It's kind of weird to support the unnamed form --vfs-mount=foo.zip if there's no way to get it. The docs even say "[the name] is how a program finds such a file system, since it has no other reference to it".
  • For --vfs-load that can make sense because you're mounting it for its behavior (and the code inside can use import.meta.dirname). Although even for --vfs-load I am not clear on the utility of making unnamed vfs mounts (even those from --vfs-load) available in workers - how is the worker supposed to get to them? I guess if the worker is itself running from a file in a vfs-load'd vfs (does that work) it can use import.meta.dirname?
• Adding a new globally accessible/mutable namespace, wherein any bit of code can mount a named VFS or look one up by name, is odd the absence of a particular reason to do so. I'd only imagined exposing the CLI-provided ones, not arbitrary programatic ones mounted later. I'm not mortally against this but would want to see documented use cases; new code-accessible global registries shouldn't be added lightly.
• It is surprising to me to make the name a fixed property of the VFS provider itself. I would expect it to be an argument to .mount() (assuming we continue to have names at all, per the last bullet).
• You mentioned wanting to be able to determine the order of --vfs-mounts. This does that for names that are not nonnegative integers. If we intend people to rely on this order, that should be documented (and tested).
• Command line options are almost without exception last-wins, not first-wins as you've done here in the case of duplicate names.

[pipobscure]

@bakkot something you said last night and your comment above ruminated with me and I think you’re right.

You said something like “it’s not like you can just fs.readdir /dev/null/vfs”

I think that might actually be the natural solution here.

• make the name an argument of mount
• mount creates a virtual symlink of name to its layer
• and we simply have fs calls to /dev/null/vfs handled so that you can actually just list them.

Thoughts?

@mcollina this is probably something you should be aware of to vociferously object if you disagree.

[pipobscure]

• For --vfs-load that can make sense because you're mounting it for its behavior (and the code inside can use import.meta.dirname). Although even for --vfs-load I am not clear on the utility of making unnamed vfs mounts (even those from --vfs-load) available in workers - how is the worker supposed to get to them? I guess if the worker is itself running from a file in a vfs-load'd vfs (does that work) it can use import.meta.dirname?

Workers get the same —vfs-mount flags in the same order. Since they are run before startup in he same order and layer numbers are deterministic by order it will have the same initial mounts as the main process. So a worker can be pointed at the same import.meta.dirname relative to the main calling it. This already works and has tests.

[pipobscure]

Also notice to @jasnell as you were the one to originally critique the version of names I had proposed. I think this actually meets the issues you had as well, but worth double checking.

And thanks again to @bakkot ! Pushback makes things better. It did for the original ZipArchives re wide tests, and it does here. I appreciate you taking the time.