René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"fs.mkdir(path, { recursive: true }) never returns when an intermediate mkdir fails with ENOENT although its parent exists (e.g. under /proc)","articleBody":"### Version\n\nv24.18.0 and v22.22.2 (both reproduce)\n\n### Platform\n\nLinux 7.0.0-38-generic x86_64, Ubuntu 26.04.1 LTS; libuv 1.52.1\n\n### Subsystem\n\nfs\n\n### What steps will reproduce the bug?\n\n```sh\n# sync: never returns, main thread at 100 % CPU\nnode -e \"require('fs').mkdirSync('/proc/nope/deeper', { recursive: true })\"\n\n# async: the promise never settles, process never exits, CPU busy\nnode -e \"require('fs/promises').mkdir('/proc/nope/deeper', { recursive: true }).then(() => console.log('ok'), (e) => console.log('err', e.code))\"\n```\n\nBoth hang until killed (`timeout 20 node ...` exits 124).\n\nThe precondition is a filesystem where `mkdir` of a child fails with `ENOENT` while the parent exists and is a directory. procfs does exactly that:\n\n```\n$ mkdir /proc/nope\nmkdir: cannot create directory '/proc/nope': No such file or directory\n```\n\nsysfs answers `EACCES` instead and the call fails fast, as expected. A plain `fs.mkdirSync('/proc/nope')` (non-recursive) also fails fast with `ENOENT`.\n\n### How often does it reproduce? Is there a required condition?\n\nAlways, on any path whose intermediate component cannot be created and whose filesystem reports `ENOENT` for that `mkdir` (procfs; presumably some FUSE / network filesystems too).\n\n### What is the expected behavior? Why is that the expected behavior?\n\nReject / throw with the `mkdir` error (`ENOENT` here, as the non-recursive call does), the same way `EACCES`, `EPERM`, `ENOSPC` and `ENOTDIR` are already returned by the recursive implementation.\n\n### What do you see instead?\n\nThe call never completes. Sync: the main thread spins. Async: the request bounces between the event loop and the libuv threadpool forever — on a hung process we measured ~24.5 M voluntary context switches in 18 minutes (~22 k/s), RSS flat at ~40 MB, `wchan` `ep_poll`.\n\n### Additional information\n\nLooking at `src/node_file.cc` (v24.18.0):\n\n- `MKDirpSync` (L1759): in `case UV_ENOENT` (L1792) the failed path and its `dirname` are pushed back onto the continuation stack. The outer loop pops the parent (`/proc`), `uv_fs_mkdir` returns `EEXIST`, the `default:` branch `stat`s it, sees a directory and `break`s. The loop then pops `/proc/nope` again, `mkdir` returns `ENOENT` again, the same two paths are pushed again, and so on. Nothing records that the parent was just verified to exist, so the state machine cycles forever.\n- `MKDirpAsync` (L1827, `case UV_ENOENT` at L1873) has the same structure, so the async variant spins as well.\n\nA possible fix: when `mkdir(child)` returns `ENOENT` right after its parent was created or confirmed to be an existing directory, stop and return `ENOENT` instead of pushing the pair again (e.g. remember the last confirmed parent in the continuation data, or bound the number of `ENOENT` retries per path).\n\nHow we hit it: a test used `/proc/…/file.json` as an \"unwritable path\" for a fail-open on-disk store. The store's debounced write called `mkdir(dirname, { recursive: true })`; under host load the write fired before the `node --test` child exited, and the child spun for 2.3 hours in three separate CI runs before anyone noticed. Related earlier report about recursive mkdir error mapping: #47098.","author":{"url":"https://github.com/genlorem","@type":"Person","name":"genlorem"},"datePublished":"2026-10-21T08:56:57Z","url":"https://github.com/nodejs/node/issues/66890"}