何が問題か

確認してから作る、では間に合わない

いちばん自然に思いつくのはこう書く形である。

if (!existsSync(LOCK)) {
	writeFileSync(LOCK, '取った');   // ← ここに来るまでに、もう一方も通り抜けている
	// 処理を始める
}

確認してから作るまでの間に、もう一方が同じ確認を通り抜ける。どちらも「無かった」と判断して両方が処理を始める。時間の隙間はごく短いが、毎時走る処理が何百回と繰り返せばいずれ当たる。

必要なのは「無ければ作る」を、途中で割り込まれない一続きの操作として OS に任せることである。

名前を変える方式は移植できない

UNIX 系では、自分だけの名前で作ってから目的の名前に変える書き方が使われる。

echo $$ > lock.$$        # 自分の pid で作る
mv lock.$$ lock          # 目的の名前へ移す

POSIX の rename(2) は、既にあるものを原子的に置き換える。同時に走っても最後の 1 つが残り、それ以外は上書きされて消える……ように見えるが、全員が「成功した」と判断してしまうため、この形は POSIX でもそのままでは排他にならない（ハードリンクの数を数えるなどの一手間が要る）。

そして Windows では処理系によって挙動が割れる。次章の実測が示すとおり、同じ「移動」でも失敗するものと黙って上書きするものがある。

実測した結果

先に first と書いたファイル（またはフォルダ）を置き、後から来た側が同じ名前を取ろうとしたときにどうなるかを測った。

Node.js 26.8.1 / Bun 1.4.0

Bun は Node 互換の API を持つ。同じコードを両方で走らせたところ、結果は完全に一致した。

Deno 1.31.1

API の名前は違うが、結果は Node と同じだった。例外の型が AlreadyExists になる点だけが異なる。

PowerShell 7.6.5

PowerShell は既定で安全側に倒れている。-Force が排他を壊す。

PowerShell から呼ぶ .NET / C#

cmd（コマンドプロンプト）

使ってよい書き方

いずれも「作りに行って、失敗したら諦める」形になっている。先に確認しない。

Node.js / Bun

import { writeFileSync, rmSync } from 'node:fs';

/** 印を置けたら true、既にあれば false */
function acquire(lockPath, owner) {
	try {
		// wx は O_CREAT | O_EXCL。「無ければ作る」を OS が一続きで行う
		writeFileSync(lockPath, owner, { flag: 'wx' });
		return true;
	} catch (err) {
		if (err.code === 'EEXIST') return false;
		throw err;   // 権限が無い等は別の話なので、握りつぶさない
	}
}

function release(lockPath) {
	rmSync(lockPath, { force: true });
}

Deno

function acquire(lockPath, owner) {
	try {
		Deno.writeFileSync(lockPath, new TextEncoder().encode(owner), { createNew: true });
		return true;
	} catch (err) {
		if (err instanceof Deno.errors.AlreadyExists) return false;
		throw err;
	}
}

PowerShell

function Get-Lock {
	param([string] $LockPath, [string] $Owner)
	try {
		# -Force を付けないこと。付けると既にある印を上書きしてしまう
		New-Item -ItemType File -Path $LockPath -Value $Owner -ErrorAction Stop | Out-Null
		return $true
	} catch [System.IO.IOException] {
		return $false
	}
}

より確実にしたい場合は .NET を直接呼ぶ。FileMode.CreateNew は「既にあれば例外」が仕様として明記されている。

try {
	$fs = New-Object System.IO.FileStream($LockPath, [System.IO.FileMode]::CreateNew)
	$fs.Close()
	# 取れた
} catch [System.IO.IOException] {
	# 取れなかった
}

cmd

フォルダを印にする。mkdir は既にあれば ERRORLEVEL 1 を返す。

mkdir "%LOCK_DIR%" 2>nul
if errorlevel 1 (
	echo 別の処理が動いています
	exit /b 1
)

rem ここから本処理

rmdir "%LOCK_DIR%"

使ってはいけない書き方

見分け方

迷ったら「既にあったらどうなるか」が名前や引数に書かれているかを見る。

印を運用する

取れるようになっただけでは足りない。置いたまま終わった印をどうするかを決めておかないと、いずれ全部が止まる。

握ったまま終わったとき

処理の最後で必ず消すよう書いても、強制終了させられれば残る。残ったままだと、以降どの処理も永久に取れない。誰も気づかないまま止まり続ける。

印に開始時刻を書いておき、一定より古ければ残骸とみなして奪う。しきい値は処理にかかる最大時間より十分長く取る。タスクに実行時間の上限を設けているなら、その数倍が目安になる。

/** 印が効いているか。古すぎるものは残骸とみなす */
function isLockActive(file, staleMs) {
	if (!existsSync(file)) return false;
	if (staleMs <= 0) return true;          // 人が置いた印は奪わない
	return Date.now() - statSync(file).mtimeMs < staleMs;
}

中身に何を書くか

空でも排他は働くが、誰が握っているのか分からないと、消してよいか判断できない。次の 3 つを書いておく。

hourly が 2026/08/30 10:03:12.481 に開始しました（pid 41244）

待つか、諦めるか

取れなかったときの振る舞いを決める。定期実行なら諦めてよいことが多い。次の回に取り直せるためである。

印だけに頼らない

印はぶつからないための工夫であって、ぶつかっても壊れない保証ではない。作業用のフォルダを処理ごとに分ける、出力先の名前を重ならないようにするなど、万一同時に走っても壊れない作りを併せて持たせる。