When `fs.cp`/`fs.cpSync` is called with both `verbatimSymlinks: true`
and a `filter` function, directory symlinks were incorrectly created
as file symlinks on Windows.

Without a `filter`, cp takes the C++ fast path (`cpSyncCopyDir`) which
uses `std::filesystem::copy_symlink()` and preserves the symlink type
automatically. With a `filter`, the JS fallback calls `symlinkSync`/
`symlink` without a `type` argument. On Windows, that causes the type
to be auto-detected by stat-ing the resolved target at the destination,
but during a recursive copy the target directory may not exist yet at
the destination (e.g. `linked/` is copied before `packages/` in
alphabetical order). The stat fails and `type` falls back to `'file'`,
producing a file symlink in place of a directory symlink.

Detect the symlink type from the source (which always exists) via
`internalModuleStat(src)` and pass it explicitly to the `symlinkSync`/
`symlink` call sites. `onLink` already computed `srcIsDir` for
subdirectory validation; hoist that computation above the early-return
paths and thread the derived `symlinkType` through `copyLink` as well.
Both the sync (`cp-sync.js`) and async (`cp.js`) implementations are
fixed.

Add two regression tests that copy a tree containing a relative
directory symlink with `verbatimSymlinks: true` and a `filter`
function, then assert the destination link still resolves as a
directory.

Fixes: #62653
Signed-off-by: shulaoda <165626830+shulaoda@users.noreply.github.com>
PR-URL: #62654
Reviewed-By: Aviv Keller <me@aviv.sh>
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: Stefan Stojanovic <stefan.stojanovic@janeasystems.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>

When `fs.cp`/`fs.cpSync` is called with both `verbatimSymlinks: true`
and a `filter` function, directory symlinks were incorrectly created
as file symlinks on Windows.

Without a `filter`, cp takes the C++ fast path (`cpSyncCopyDir`) which
uses `std::filesystem::copy_symlink()` and preserves the symlink type
automatically. With a `filter`, the JS fallback calls `symlinkSync`/
`symlink` without a `type` argument. On Windows, that causes the type
to be auto-detected by stat-ing the resolved target at the destination,
but during a recursive copy the target directory may not exist yet at
the destination (e.g. `linked/` is copied before `packages/` in
alphabetical order). The stat fails and `type` falls back to `'file'`,
producing a file symlink in place of a directory symlink.

Detect the symlink type from the source (which always exists) via
`internalModuleStat(src)` and pass it explicitly to the `symlinkSync`/
`symlink` call sites. `onLink` already computed `srcIsDir` for
subdirectory validation; hoist that computation above the early-return
paths and thread the derived `symlinkType` through `copyLink` as well.
Both the sync (`cp-sync.js`) and async (`cp.js`) implementations are
fixed.

Add two regression tests that copy a tree containing a relative
directory symlink with `verbatimSymlinks: true` and a `filter`
function, then assert the destination link still resolves as a
directory.

Fixes: #62653
Signed-off-by: shulaoda <165626830+shulaoda@users.noreply.github.com>
PR-URL: #62654
Reviewed-By: Aviv Keller <me@aviv.sh>
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: Stefan Stojanovic <stefan.stojanovic@janeasystems.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>