fix(windows): avoid execute access when renaming files

[steipete]

Windows internal renames open the source with FILE_TRAVERSE. For a regular file, that bit is FILE_EXECUTE. Reopening freshly written compile-cache entries with it makes Defender scan them synchronously before granting access: a native trace recorded 2,001 OnOpen scans totaling 23.703 seconds during a 28.093-second flush.

Use the existing non-executable fallback rights for the first and only open. Keep SYNCHRONIZE | GENERIC_WRITE | DELETE, the sharing defaults, and the open/rename options. Delete the redundant retry. Remaining FILE_TRAVERSE call sites explicitly open directories.

Validation:

• Interleaved Windows API controls over 2,000 unique cache-like files: reopen calls took 24.532/24.509 seconds with execute access and 0.119/0.116 seconds without it. Defender stayed enabled.
• Actual cold-cache flush: 29.545 seconds before and 3.821 seconds after, with all 2,001 entries published. The original module regression and surrounding filesystem checks pass with the change.
• Windows runtime measurements use openclaw/bun#130, whose entire changed Windows helper file is byte-identical to this port. That fork also passed all 12 Rust target checks and both native CI lanes; this upstream commit passes cargo check -p bun_sys for x86_64-pc-windows-msvc and aarch64-pc-windows-msvc.
• Independent review through P2 is clean. No cache policy or test deadline changes.

Standalone explicit-flush reproduction

Run this script with a current Bun executable on Windows with Defender enabled. The optional argument selects the child executable; fixture creation is outside the measured flush. The same script was also verified with Node 24.21.0 on macOS.

import { spawnSync } from "node:child_process";
import fs from "node:fs";
import os from "node:os";
import path from "node:path";

const binary = process.argv[2] ?? process.execPath;
const root = fs.mkdtempSync(path.join(os.tmpdir(), "compile-cache-repro-"));
const count = 2_000;
const functions = Array.from({ length: 64 }, (_, i) => `function f${i}(x) { return x + ${i}; }`).join("\n");
try {
  for (let i = 0; i < count; i++) {
    fs.writeFileSync(path.join(root, `mod${i}.cjs`), `${functions}\nmodule.exports = f63(${i});`);
  }
  fs.writeFileSync(path.join(root, "main.cjs"), `
    const fs = require("node:fs");
    const moduleApi = require("node:module");
    const loadStarted = performance.now();
    for (let i = 0; i < ${count}; i++) require("./mod" + i + ".cjs");
    const loadMs = performance.now() - loadStarted;
    const started = performance.now();
    const cpu = process.cpuUsage();
    moduleApi.flushCompileCache();
    console.log(JSON.stringify({
      revision: globalThis.Bun?.revision ?? process.version,
      platform: process.platform,
      loadMs,
      flushMs: performance.now() - started,
      cpu: process.cpuUsage(cpu),
      entries: fs.readdirSync(moduleApi.getCompileCacheDir()).length,
    }));
  `);
  const env = { ...process.env, NODE_COMPILE_CACHE: path.join(root, "cache"), NODE_DEBUG_NATIVE: "", BUN_ENABLE_CRASH_REPORTING: "0", BUN_RUNTIME_TRANSPILER_CACHE_PATH: "0" };
  delete env.NODE_DISABLE_COMPILE_CACHE;
  const child = spawnSync(binary, [path.join(root, "main.cjs")], { env, encoding: "utf8" });
  process.stdout.write(child.stdout ?? "");
  process.stderr.write(child.stderr ?? "");
  if (child.error) throw child.error;
  if (child.status !== 0) throw new Error(`Child exited with ${child.status}, signal ${child.signal}`);
} finally {
  fs.rmSync(root, { recursive: true, force: true });
}

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository: oven-sh/bun/.coderabbit.yaml
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: b3d0b771-c656-446e-b6eb-45ee461f600d

📥 Commits

Reviewing files that changed from the base of the PR and between 13a98b0 and bbee63a.

📒 Files selected for processing (1)

• src/sys/windows/mod.rs

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

---

Walkthrough

rename_at_w now opens the source with SYNCHRONIZE | GENERIC_WRITE | DELETE in one attempt. If the open fails, it returns the error.

Changes

Windows rename

Layer / File(s)	Summary
Open the rename source src/sys/windows/mod.rs	rename_at_w removes the open attempt with FILE_TRAVERSE and its retry. It opens the source once with `SYNCHRONIZE

Suggested reviewers: dylan-conway

Priority: ➖ Normal

Merge Risk: ⚪ Minimal · up to bbee6

No merge-blocking issue is identified; the Windows rename change is ready for normal checks.

Security Architecture Review

Security architecture risk: ⚪ Minimal · up to bbee6

The change requests fewer permissions using a fallback already supported by the previous implementation. Rename permissions, handle-based file identity, and cleanup remain intact. No material security regression was identified in the reviewed path.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The affected authority remains the Windows filesystem paths and directory handles supplied by existing rename callers, subject to native access checks. The change neither adds a caller nor introduces a new credential or privilege mechanism in the inspected path.

Security Findings and Attack Paths

• inferred — The removed execute-access request was not a mandatory security gate: the base already retried every initial open error using the head's reduced rights. This counterevidence does not support an introduced permission-bypass attack path.

Trust Boundaries and Controls

• observed — Native source-open authorization, relative-directory resolution, and handle-based rename authority remain in place. FILE_OPEN_REPARSE_POINT is preserved; this is not a claim that all path components are sandboxed or that absolute paths are prohibited.

Resilience and Maintainability Implications

• inferred — The change preserves source-handle ownership and cleanup on normal return and unwinding, including rename failure. Repetition and concurrency use the same single handle-based rename operation as before; no new partially committed multi-step transition is introduced. Process termination and adversarial filesystem races were not runtime-verified.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly summarizes the main change: avoiding execute access when renaming files on Windows.
Description check	✅ Passed	The description explains the change and its rationale, and provides detailed validation results. It covers both required template sections, although it uses “Validation” instead of the exact heading “…

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Commit to this branch
• Create a new PR

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

_{Comment @coderabbitai help to get the list of available commands.}