René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Inconsistent `retryDelay` in `fs.rmSync` and asynchronous `fs.rm` (on Windows)","articleBody":"### Version\n\nv24.17.0\n\n### Platform\n\n```text\nMicrosoft Windows NT 10.0.26200.0 x64\n```\n\n### Subsystem\n\nfs\n\n### What steps will reproduce the bug?\n\nThe current workspace\n```\neperm-folder\n|---> locked-file.txt\nlocking.py\nindex.js\n```\n\n\u003cbr>\n\n`locking.py`\n```python\nimport os, signal\nos.makedirs(\"eperm-folder\", exist_ok=True)\n\nfilepath = \"eperm-folder/locked-file.txt\"\nprint(f\"locking {filepath} indefinitely, until SIGINT\")\nfd = os.open(filepath, os.O_RDWR | os.O_CREAT )\nos.write(fd, b'Hello, World!')\ndef sigterm_handler(s, f):\n    os.close(fd)\n    exit(0)\nsignal.signal(signal.SIGINT, sigterm_handler)\nwhile True:\n    pass\n```\n\n`index.js`\n```js\nconst fs = require('node:fs');\nconst fsPromises = require('node:fs/promises');\nconst path = require('node:path')\nconst { spawn } = require('node:child_process')\nconst filepath = \"eperm-folder/locked-file.txt\"\nif (fs.existsSync(filepath)) {\n    console.log('deleting eperm-folder/')\n    const start = performance.now()\n    try { \n        fs.rmSync(path.dirname(filepath), { recursive: true, retryDelay: 5 * 1000, maxRetries: 1 })\n    }\n    catch (e){\n        console.log(e)\n        const duration = performance.now() - start;\n        console.log(`rmSync - ${duration} ms`)\n    }\n}\n```\n\n**Steps to run:**\n1. Run `python locking.py` first\n- this is to create `eperm-folder/locked-file.txt` and to indefinitely lock the file  (simulating an `EPERM`/`EBUSY` error)\n\n2. Then run `node index.js`\n\n\n### How often does it reproduce? Is there a required condition?\n\nAlways, this is specific to Windows, and only when the file / directory is locked by another process.\n\n### What is the expected behavior? Why is that the expected behavior?\n\nThe time elapsed should be more than `5000ms` given it is our `retryDelay` value\n\nFor comparison, in the asynchronous `fs.rm` functions, the time elapsed is around `15,000ms` which is what we expect\n\nHere's a reproducible script for the asynchronous `fs.rm` functions\n```js\nconst fs = require('node:fs');\nconst fsPromises = require('node:fs/promises');\nconst path = require('node:path')\nconst filepath = \"eperm-folder/locked-file.txt\"\n\nif (fs.existsSync(filepath)) {\n    console.log('deleting eperm-folder/')\n    const start = performance.now()\n        fs.rm(\n            path.dirname(filepath), \n            { recursive: true, retryDelay: 5 * 1000, maxRetries: 1 },\n            (e) => {\n                if (e)\n                    console.error(e)\n                const duration = performance.now() - start;\n                console.log(`async fs.rm() - ${duration} ms`)\n            }\n        )\n}\n```\n\nThis means that in the `fs.rmSync`, retries are not delayed\n\n### What do you see instead?\n\nThe time elapsed in the `fs.rmSync` operation is between `1-30 ms` (on my end)\n\n### Additional information\n\nThis affects other retryable errors in Windows (e.g., `EMFILE`, `ENFILE`, `ENOTEMPTY`)\nMight be related to https://github.com/nodejs/node/issues/55555, but this is Windows-specific\n\n","author":{"url":"https://github.com/louiellan","@type":"Person","name":"louiellan"},"datePublished":"2026-06-20T01:24:51Z","url":"https://github.com/nodejs/node/issues/64016"}