René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"`fs.cp` creates file symlink instead of directory symlink on Windows when `filter` is provided","articleBody":"### Version\n\nv24.14.1 (also affects v25.9.0)\n\n### Platform\n\nWindows 11 Pro 10.0.26200\n\n### What steps will reproduce the bug?\n\n```javascript\nimport fs from 'node:fs';\nimport path from 'node:path';\nimport os from 'node:os';\n\nconst tmp = path.join(os.tmpdir(), 'repro-' + Date.now());\nconst src = path.join(tmp, 'src');\nconst dest1 = path.join(tmp, 'dest-no-filter');\nconst dest2 = path.join(tmp, 'dest-with-filter');\n\n// Create a source directory with a relative directory symlink\nfs.mkdirSync(path.join(src, 'packages', 'my-lib'), { recursive: true });\nfs.writeFileSync(path.join(src, 'packages', 'my-lib', 'index.js'), 'hello');\nfs.mkdirSync(path.join(src, 'linked'), { recursive: true });\nfs.symlinkSync(\n  path.join('..', 'packages', 'my-lib'),\n  path.join(src, 'linked', 'my-lib'),\n  'dir'\n);\n\n// Test 1: verbatimSymlinks WITHOUT filter — works\nfs.cpSync(src, dest1, { recursive: true, verbatimSymlinks: true });\nconsole.log('without filter:', fs.statSync(path.join(dest1, 'linked', 'my-lib')).isDirectory()); // true\n\n// Test 2: verbatimSymlinks WITH filter — broken\nfs.cpSync(src, dest2, { recursive: true, verbatimSymlinks: true, filter: () => true });\nconsole.log('with filter:', fs.statSync(path.join(dest2, 'linked', 'my-lib')).isDirectory()); // EPERM\n\nfs.rmSync(tmp, { recursive: true, force: true });\n```\n\n### How often does it reproduce? Is there a required condition?\n\nAlways reproducible on Windows. Requires `verbatimSymlinks: true` combined with a `filter` function (even `() => true`).\n\n### What is the expected behavior? Why is that the expected behavior?\n\nBoth cases should produce a working directory symlink. The `filter` option should not affect the symlink type — `filter: () => true` is semantically identical to no filter.\n\n### What do you see instead?\n\nWithout `filter`: the directory symlink is preserved correctly (`Directory, ReparsePoint`).\n\nWith `filter`: a file symlink is created instead (`Archive, ReparsePoint`). Subsequent `stat()`, `readdir()`, and `realpathSync()` on the copied symlink all fail with `EPERM`.\n\n### Root cause\n\n`fs.cp` takes two different code paths depending on whether `filter` is provided:\n\n- **Without `filter`**: Uses the C++ fast path (`fsBinding.cpSyncCopyDir`) which calls `std::filesystem::copy_symlink()` — this automatically preserves the symlink type.\n\n- **With `filter`**: Falls back to the JavaScript path in `lib/internal/fs/cp/cp-sync.js`, where `onLink()` calls `symlinkSync(resolvedSrc, dest)` **without the `type` parameter**.\n\nWhen `type` is omitted, `symlinkSync` tries to auto-detect by calling `statSync(resolve(dest, '..', target))`. However, during a recursive copy, the symlink's target directory may not yet exist at the destination (e.g., `linked/` is copied before `packages/` in alphabetical order). When stat fails, `type` defaults to `null`, which results in a **file symlink** on Windows.\n\nThe same issue exists in the async version (`lib/internal/fs/cp/cp.js`).\n\n### Related Issue\n\n- https://github.com/vitejs/vite/pull/22196#discussion_r3056981191","author":{"url":"https://github.com/shulaoda","@type":"Person","name":"shulaoda"},"datePublished":"2026-04-09T16:15:39Z","url":"https://github.com/nodejs/node/issues/62653"}