What the test verifies vs. what it should

The tests check two things: (1) lstatSync().isSymbolicLink() returns true, and (2) readFileSync() returns the expected file content. Neither check calls readlinkSync() to verify that the copied symlink points to the same target as the original symlink.

The specific code path this masks

On Linux, when open(src, O_NOFOLLOW) returns ELOOP (because src is a symlink), the ELOOP branch at ~L6412 calls Syscall.symlink(src, dest). This uses src's file path (e.g. /tmp/x/link.md) as the new link target, rather than what src actually points to (e.g. /tmp/x/target.md). The correct behavior — matching Node.js — is to call readlink(src) first and then create dest pointing to that result.

Why existing checks do not catch it

The test creates link.md -> /abs/path/target.md with an absolute path. The buggy copy creates out2/link.md -> /abs/path/link.md (a chain). isSymbolicLink() returns true — out2/link.md is indeed a symlink, just to the wrong target. readFileSync() follows the chain out2/link.md -> link.md -> target.md and returns '# Hello'. Both assertions pass despite the semantically incorrect copy.

Step-by-step proof

1. symlinkSync('/tmp/x/target.md', '/tmp/x/link.md') — link.md points to /tmp/x/target.md
2. cpSync('/tmp/x/link.md', '/tmp/x/out2/link.md') — Linux ELOOP branch runs Syscall.symlink('/tmp/x/link.md', '/tmp/x/out2/link.md')
3. readlinkSync('/tmp/x/out2/link.md') returns '/tmp/x/link.md' (wrong — should be '/tmp/x/target.md')
4. lstatSync('/tmp/x/out2/link.md').isSymbolicLink() -> true (passes incorrectly)
5. readFileSync('/tmp/x/out2/link.md') follows the chain -> '# Hello' (passes incorrectly)

How to fix the test

Add after the readFileSync assertion in both tests:

expect(readlinkSync(join(root, 'out2/link.md'))).toBe(readlinkSync(join(root, 'link.md')));

This directly compares the symlink targets and would immediately expose the ELOOP branch wrong-target behavior if present.

Scope

This is a test quality issue, not a production-code defect introduced by this PR. The primary fix (ENOENT/parent dir creation) is correctly tested. The missing assertion provides false confidence that the Linux ELOOP path produces a semantically correct symlink copy.

What the bug is: All three new symlink retry paths use bun.makePath(...) catch {} / bun.makePathW(...) catch {}, which silently discards any error from the directory-creation step. This affects the macOS symlink branch (L6305), the Linux ELOOP branch (L6419), and the Windows branch (L6607).

How it manifests: When makePath fails for a reason other than normal I/O (e.g., EACCES on the parent's parent, EROFS on a read-only filesystem), the discarded error means the destination directory is never created. The subsequent retry call (copyfile, symlink, or CreateSymbolicLinkW) then also fails — but with ENOENT (no directory), not with the actual root cause. The caller therefore receives a misleading error code.

Code path (Linux ELOOP example):

1. First open(src, O_NOFOLLOW) returns ELOOP → enter symlink branch.
2. Syscall.symlink(src, dest) fails with ENOENT (destination dir missing).
3. bun.makePath(...) catch {} is called but fails with EACCES — error discarded.
4. Syscall.symlink(src, dest) is retried and fails again with ENOENT (dir still missing).
5. Caller receives ENOENT instead of EACCES.

Why existing code doesn't prevent it: The catch {} intentionally silences errors. On success, makePath returns nothing; on failure, the error value is thrown and immediately caught and discarded. There is no branch to inspect the failure cause.

Contrast with the Linux regular-file path (~L6460-6466): That path calls mkdirRecursive and explicitly checks the return value, propagating the mkdir error immediately if non-nil. This is the correct pattern and what should be followed here.

Addressing the refutation: One verifier noted that the macOS regular-file path (L6397, unchanged by this PR) also uses catch {}, so the new code follows the pre-existing macOS convention rather than introducing a new inconsistency. This is a valid point — the pattern is not new. However, the Linux symlink path now diverges within the same platform from the Linux regular-file path's better error handling, and the new Windows and macOS symlink paths could likewise be improved. Following a pre-existing weaker pattern does not make the pattern correct.

Impact: The operation still fails in all these scenarios — no data corruption or correctness issue. The only effect is that the error code reported to the user is misleading (ENOENT instead of EACCES/EROFS/EDQUOT), making debugging harder. Severity: nit.

Fix: Check makePath's result and return the mkdir error if it failed, matching the Linux regular-file pattern. For example on the Linux ELOOP branch:

if (bun.makePath(std.fs.cwd(), bun.path.dirname(dest, .auto))) |_| {} else |mkdir_err| return .{ .err = mkdir_err };
return Syscall.symlink(src, dest);

What the bug is and how it manifests

The PR adds four new calls to std.fs.cwd() in src/runtime/node/node_fs.zig:

• L6489 — macOS symlink branch: bun.makePath(std.fs.cwd(), bun.path.dirname(dest, .auto)) catch {};
• L6603 — Linux ELOOP branch: same call
• L6761 — Linux MLINK/LOOP branch: same call
• L6902 — Windows branch: bun.makePathW(std.fs.cwd(), bun.path.dirnameW(dest)) catch {};

std.fs.cwd is a banned word in test/internal/ban-words.test.ts:44 (reason: "Prefer bun.FD.cwd()"), and test/internal/ban-limits.json:39 caps the repo-wide count at 109 instances. Adding 4 more pushes the count over the limit, so ban-words.test.ts fails with exit code 1.

The specific code path that triggers it

test/internal/ban-words.test.ts greps src/**/*.zig (excluding src/codegen, src/deps, src/unicode/uucode) for each banned phrase, compares the count against ban-limits.json, and throws if the count exceeds the recorded limit. Before this PR node_fs.zig contained 4 occurrences of std.fs.cwd(); after the PR it contains 8. The repo-wide count rises from ≤109 to ~113, exceeding the cap.

Why existing code doesn't prevent it

The only enforcement is the ban-words CI test itself, which is now failing. src/CLAUDE.md documents the same guideline ("std.fs.cwd() → bun.FD.cwd()") but is advisory only. CodeRabbit flagged this in an inline comment, but its suggested replacement bun.FD.cwd().stdDir() is itself banned (ban-words.test.ts:48: ".stdDir()" → "Prefer bun.FD or bun.sys, or convince Jarred why this exception is necessary"), so applying that suggestion would just trade one CI failure for another.

Step-by-step proof

1. test/internal/ban-limits.json:39 → "std.fs.cwd": 109.
2. git grep -c 'std\.fs\.cwd' -- 'src/**/*.zig' on the base commit (excluding src/codegen, src/deps, src/unicode/uucode) → ≤109.
3. PR diff adds exactly 4 new std.fs.cwd() literals and removes none; ban-limits.json is not bumped.
4. Post-PR count → ≥113 > 109.
5. ban-words.test.ts throws "std.fs.cwd" is banned … found N > 109 instances → exit code 1.
6. robobun's CI report for Build #50563 confirms test/internal/ban-words.test.ts failing with code 1 on all 15 platforms (Linux x64/aarch64/asan/baseline, Alpine, macOS x64/aarch64, Windows x64/aarch64).

Impact

Hard CI break on every platform — blocks merge.

How to fix

Avoid std.fs entirely. The Linux regular-file fallback in this same function (~L6644) already shows the preferred pattern:

this.mkdirRecursive(.{
    .path = .{ .string = bun.PathString.init(bun.path.dirname(dest, .auto)) },
    .recursive = true,
});

Using this.mkdirRecursive(...) for the macOS/Linux branches and the equivalent bun.sys path for Windows removes the std.fs.cwd() calls (and, as a bonus, also addresses the "swallowed mkdir error" nit raised separately). Alternatively bun.FD.cwd().asDir() could be used if bun.makePath must be kept, but switching to the existing mkdirRecursive helper is the cleaner option since it's already used a few lines below for the same purpose. Bumping ban-limits.json would also make CI green but is discouraged — the codebase is actively migrating away from std.fs.

What the issue is

Both CLAUDE.md (line ~66) and test/CLAUDE.md (line ~153) document that test/regression/issue/${issueNumber}.test.ts is reserved "only for bugs that have a GitHub issue number and are true regressions (worked in a previous release, then broke). An issue number alone does not qualify — if it was never correct, put the test in the module's existing test file instead."

This PR adds test/regression/issue/28997.test.ts, but per the PR description's own "Cause" section, the symlink branches in _copySingleFileSync simply never had the ENOENT→makePath retry that the regular-file branch had. That is missing-implementation behavior — it was never correct in any prior release — rather than something that worked and later regressed.

Why the convention says it goes elsewhere

The convention exists so that test/regression/ stays a focused catalog of "this used to work, then broke" cases, while feature/correctness tests accumulate in the relevant module suite where they're discoverable alongside related coverage. test/js/node/fs/cp.test.ts already exists and is the natural home for cpSync symlink coverage.

Step-by-step

1. The guideline: test/CLAUDE.md:153 — "only for … true regressions … if it was never correct, put the test in the module's existing test file instead."
2. The PR description states the macOS/Linux/Windows symlink branches lacked the retry that the regular-file branch had — i.e., never implemented.
3. Therefore cpSync fails with ENOENT when copying symlinks into non-existent directories #28997 is a never-correct bug, not a regression.
4. Per (1), the two test cases belong in test/js/node/fs/cp.test.ts, optionally with a // https://github.com/oven-sh/bun/issues/28997 comment for traceability.

Impact

Zero functional impact — the test runs and passes correctly where it is, and is discoverable via the issue number. There are also ~400 files already in test/regression/issue/, so historical enforcement of this convention is loose. This is purely an organizational nit and should not block the PR.

How to fix

Move the two test(...) blocks into test/js/node/fs/cp.test.ts (keeping the issue-URL comment) and delete test/regression/issue/28997.test.ts.