Function _writeLockAtomic

index.js:552–606

(lockFile, payload)

} = require('./src/adapters/scripts/_lockPaths');

function _writeLockAtomic(lockFile, payload) {
  // Round-6 (§19.8): the previous implementation used tmp + rename, which
  // makes the WRITE atomic but not the OWNERSHIP claim. Two processes
  // could both rename their own tmp file over the same lockFile (rename
  // is atomic per call but successive renames overwrite each other), then
  // each read it back and -- if the second rename happened between the
  // first process's rename and its read-back -- see the OTHER process's
  // PID. Each then concludes "I lost the race" and exits, leaving the
  // lockFile owned by no live process. Symmetrically, two processes can
  // each see their own PID if the reads happen between their respective
  // renames, and both conclude they won.
  //
  // The proper primitive is link(2): given a unique tmp file, link to the
  // target path fails atomically with EEXIST if the target already
  // exists. Only one of N concurrent linkers succeeds.
  // NOTE(windows): mode 0o700 / 0o600 are silently ignored on Windows.
  // The lock directory and tmp file will NOT be owner-only on Windows.
  // Isolation relies solely on the user-profile directory ACLs.
  const dir = path.dirname(lockFile);
  try { fs.mkdirSync(dir, { recursive: true, mode: 0o700 }); } catch (_) {}
  const tmp = lockFile + '.' + process.pid + '.tmp';
  fs.writeFileSync(tmp, payload, { encoding: 'utf8', mode: 0o600 });
  // link() requires the target NOT to exist. The caller in the takeover
  // path has already unlinked the stale lockFile via fs.unlinkSync
  // (ignoring ENOENT). If a concurrent process beat us to the link, our
  // linkSync below throws EEXIST -- we surface that to the caller and
  // clean up our tmp.
  //
  // EXDEV: fs.link() fails with EXDEV when tmp and lockFile are on different
  // volumes (can happen on Windows when EVOLVER_LOCK_DIR points to a drive
  // other than the tmp dir). Fall back to renameSync, which Node.js handles
  // cross-device by copying + deleting. rename is not atomic in this path,
  // so the EEXIST guard is lost, but this is an unusual configuration and
  // the result is still safe (worst case: two daemons both think they won,
  // the second write wins, the first will exit on its next tick when it
  // reads back a foreign PID via the heartbeat).
  try {
    fs.linkSync(tmp, lockFile);
  } catch (err) {
    if (err && err.code === 'EXDEV') {
      // Cross-device: rename falls back to copy+delete inside Node.js; this
      // loses the atomic-EEXIST guarantee but is better than hard-failing.
      try {
        fs.renameSync(tmp, lockFile);
      } catch (renameErr) {
        try { fs.unlinkSync(tmp); } catch (_) {}
        throw renameErr;
      }
      return; // tmp has been consumed by renameSync, skip unlinkSync below
    }
    try { fs.unlinkSync(tmp); } catch (_) {}
    throw err;
  }
  try { fs.unlinkSync(tmp); } catch (_) {}
}

function _readLockPayload(lockFile) {
  try {