vfs: make the reserved root readable through fs

[pipobscure]

The reserved root ${os.devNull}/vfs, which holds the mount points of
all virtual file systems, could not be read: fs calls on it fell through
to the real file system, so nothing could list what was mounted.

While any file system is mounted, serve the root as a read-only
directory. It lists every mount point by the last segment of its path, a
recursive listing descends into each mounted file system, and paths
under it that no mount serves report ENOENT. Creating, removing or
changing entries in it fails with EROFS. When nothing is mounted it does
not exist, as before.

Add vfs.vfsBase(), which returns the path of that directory, so that a
program can read it without spelling the path out.

A mount point cannot be removed or renamed, nor replaced by a rename:
rmdir() and rename() fail with EBUSY, and a recursive rm() empties the
file system and then fails the same way. Before, rmdir() of an empty
mount point reported success without doing anything.

The callback and promise forms of readdir() with withFileTypes now
report each Dirent's parentPath as a host path, as readdirSync() did,
instead of the provider-relative one, and split recursive names such as
dir/file.txt into their directory and base name. A recursive listing
joins subdirectories with the host separator rather than /, which
mixed separators on Windows. realpath() of a mount point no longer
returns it with a trailing separator.

[bakkot]

The docs for vfs.mount() still say

The virtual path scheme is subject to change and users should not manually construct them based on assumptions. Instead, obtain them from what vfs.mount() returns or vfs.mountPoint.

Presumably that should be updated?

[pipobscure]

Presumably that should be updated?

The reason I left it because the feature is experimental and we're not constructing a mount-paths, but rather the well-known root of all vfs-mounts. Though that's debatable. I'll go with whatever you say, but am happy to remove it if this rationale seems too flimsy.

The question that brought up for me though is whether we want a require('node:vfs').vfsBase() that returns the base path for vfs, so that I can then use fs.readdir on it. That way the user can reliably get to the base even if we end up changing the base path. (I'd do that as a separate PR if desired)

[codecov]

Codecov Report

❌ Patch coverage is 93.56568% with 24 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.28%. Comparing base (1eacebb) to head (1f5af76).
⚠️ Report is 19 commits behind head on main.

Files with missing lines	Patch %	Lines
lib/internal/vfs/root.js	89.67%	22 Missing ⚠️
lib/internal/vfs/setup.js	96.55%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #66140      +/-   ##
==========================================
- Coverage   90.29%   90.28%   -0.02%     
==========================================
  Files         790      791       +1     
  Lines      272529   272865     +336     
  Branches    52037    52119      +82     
==========================================
+ Hits       246074   246346     +272     
- Misses      16908    16978      +70     
+ Partials     9547     9541       -6     

Files with missing lines	Coverage Δ
lib/internal/vfs/errors.js	100.00% <100.00%> (ø)
lib/internal/vfs/file_system.js	99.63% <100.00%> (+0.01%)	⬆️
lib/internal/vfs/router.js	98.93% <100.00%> (+1.46%)	⬆️
lib/vfs.js	100.00% <100.00%> (ø)
lib/internal/vfs/setup.js	87.12% <96.55%> (+0.15%)	⬆️
lib/internal/vfs/root.js	89.67% <89.67%> (ø)

... and 20 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[bakkot]

Mostly I just don't like it when docs seem to contradict themselves; I always assume I'm misreading something. (Right now one part of the docs appears to be saying "don't assume things are under devnull" and another says to enumerate devnull.)

Adding vfsBase and then changing the above note to mention that enumerating this directory is an acceptable way to obtain a mount point would resolve my concern. Or we could decide that actually it's fine to assume things will be under devnull and document that. Either way.

[pipobscure]

@mcollina, this is now the basic PR split out of the earlier one, followed by either #66119 or #66162 depending on which direction we want to take.

[pipobscure]

I'm refactoring the reservation of layerId=0 out of this branch and and into #66162. This way the two PRs are entirely independent of each other.

[pipobscure]

Note: this refactor makes #66162 and #66140 are now entirel independent of each other

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/77716/

[pipobscure]

I’m seeing the same three jobs fail on #66127, #66140 and #66162 and given I ran tests on Linux, Mac and Windows, I’m assuming it’s not related to these PRs. Could someone have a look.

[pipobscure]

I have rebased on latest main in order to include:

• Ref: 20b3a69
• Ref: 3f76564
• Ref: 194eb69

Which were merged last night and hopefully deflake tests.

If someone can verify them and retrigger CI, I'd appreciate it.

[mcollina]

lgtm

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/77750/