`mkdir` with the `recursive` flag hides `EROFS` readonly file system errors with `ENOENT`

[Silic0nS0ldier]

Version

v19.7.0

Platform

Linux 0a51b4117477 5.15.49-linuxkit #1 SMP PREEMPT Tue Sep 13 07:51:32 UTC 2022 aarch64 Linux

Subsystem

fs

What steps will reproduce the bug?

1. Clone https://github.com/Silic0nS0ldier/nodejs-mkdir-recursive-hides-erofs
2. With repo root as cwd, run commands listed in README. Reported issue is first test case.

How often does it reproduce? Is there a required condition?

Provided the target of mkdir is a read only filesystem and the directory does not already exist, this issue reproduces 100% of the time.

What is the expected behavior? Why is that the expected behavior?

An error with the error code EROFS.

What do you see instead?

An error with the error code ENOENT.

Additional information

On AMD64 systems the digest will need to be re-acquired, as this reproduction was created on an ARM64 host.

[targos]

@nodejs/fs

[kwaszczuk]

@targos I’m still encountering this issue in Node v22.13.1. From what I can see, the PR with the fix was prepared almost two years ago but wasn’t approved due to a missing test and has been abandoned since then.

@hiimjako If you don’t mind, I’d like to take over the PR and see it through to completion.

[hiimjako]

Hi @kwaszczuk!
For me, there is no problem. At the time I didn't know how to mount a read-only volume in CI, that was the problem blocking the PR, and it was the only way I knew to test it.
If you find a way to do it, that would be great!

[Silic0nS0ldier]

Something like this should produce a readonly disk (although admin/sudo privileges will be required).

# Create directory for mount
$ mkdir ~/foo

# Mount a new tmpfs volume at ~/foo
$ sudo mount -o ro,size=1M -t tmpfs none ~/foo

# Attempt to create file
$ touch ~/foo/bar
touch: cannot touch '/home/___/foo/bar': Read-only file system

# Remove mount
$ umount ~/foo

That works fine for a (Linux-only) one-off, not so much for a test case. My thinking here is;

1. The test is going to need to rely on the test environment having such a space already setup (unfortunately no directories in the filesystem hierarchy standard had the required property, or are further complicated by permissions).
2. Skip the test in environments that do not meet the requirements.

I'm not sure how macOS and Windows (which can both have readonly filesystems) would be setup for this test case. Given uv maps all platforms to the same EROFS error code, testing Linux only is probably sufficient.

[kwaszczuk]

@Silic0nS0ldier Yeah that is exactly what I already came up with: kwaszczuk@b1f3af7

I just need to take care off the mount cleanup after the tests. I should be able to finish that by the end of the next week.

The test is going to need to rely on the test environment having such a space already setup (unfortunately no directories in the filesystem hierarchy standard had the required property, or are further complicated by permissions).

We can create the respective mount in the test's setup itself. CI runs with root privilege, so it is going to work fine. I have also succeeded with creating it in CI before running tests, but I think having it encapsulated in the test itself is a better approach.