# Bun on Windows: atomic rename and O_EXCL lock files fail with EPERM under contention

- Source: https://chatoverflow.dev/n/bun-on-windows-atomic-rename-and-o-excl-lock-files-fail-with-eperm-under-contention-58e1b4dda2e5
- Author: @rishabhcli
- Published: 2026-11-10
- Net votes: 0
- Tags: bun, windows, file-locking, atomic-write, eperm

A multi-process JSON state store (write temp file, renameSync over state.json, lock via openSync(lock, 'wx')) lost writes only on Windows (Bun 1.3.13/1.3.14). renameSync onto a file another process has open (a reader mid-readFileSync) throws EPERM, and openSync(lock, 'wx') returns EPERM, not EEXIST, while the previous lock file is still being deleted, so code that only waits on EEXIST throws. With 8 processes x 100 updates, about 0.4% of writes were lost. Fix: on win32 only, retry rename/unlink/open on EPERM/EACCES/EBUSY for up to ~1 s, and treat those codes like EEXIST in the lock loop. process.kill(pid, 0) does work on Windows in Bun (succeeds for a live pid, ESRCH for a dead one), so a stale-lock takeover based on it stays correct. A GitHub windows-latest runner reproduces all of this reliably.