知識マップ: ファイル連携の排他制御の基礎知識 - ファイルロックと原子的 claim のベストプラクティス

記事「ファイル連携の排他制御の基礎知識 - ファイルロックと原子的 claim のベストプラクティス」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

この記事は、共有フォルダや夜間バッチでのファイル連携を、OSロック任せではなく受け渡しプロトコルとして設計する考え方を整理する。読む前に処理権を原子的claimで確保し、生成中のファイルはtemp名に閉じ込めてcloseしたあとfinal名へrenameして公開し、完了はサイズやタイムスタンプで推測せずdone・manifestで明示する。lock fileを使うならownerIdやexpiresAtを持つlease形式にしてstale lockに備え、Windowsのbyte-range lockがメモリマップファイルでは無視されることやadvisory lockが約束を無視する相手には効かないことを踏まえたうえで、最後は同じ入力を再処理しても壊れないidempotencyで受け止める設計が実務では強いと結論づける。

flowchart LR
    accTitle: ファイル連携の排他制御の知識マップ
    accDescr: 受け渡しプロトコルが原子的claim・temp->rename公開・done/manifest・lease化したlock file・idempotencyをどう組み合わせ、二重処理や書き込み途中の読み込みなどの事故をどのアンチパターンに対応させて防ぐかを示す図
    file_handoff_protocol["受け渡しプロトコル"]
    atomic_claim["原子的claim"]
    temp_then_rename_publish["temp -> close -> rename/replaceでの公開"]
    done_manifest_file["done/manifestファイル"]
    lock_file_lease["lease化したlock file"]
    idempotent_processing["idempotency(冪等性)を前提にした処理"]
    os_file_lock["OSファイルロック(OSロック)"]
    atomic_creation["原子的作成(CreateNew / O_CREAT|O_EXCL)"]
    duplicate_processing["二重処理(二重計上・二重送信・更新の消失)"]
    exists_then_create_antipattern["Exists->Createの二段階チェック"]
    direct_final_write_antipattern["最終ファイル名への直接書き込み"]
    partial_write_read["書き込み途中ファイルの読み込み事故"]
    size_stability_completion_check["ファイルサイズ安定待ちによる完了判定"]
    shared_file_mutual_update_antipattern["共有ファイルの相互更新アンチパターン"]
    stale_lock["stale lock"]
    byte_range_lock["byte-range lock(範囲ロック)"]
    heterogeneous_system_integration["異種システム連携"]
    advisory_lock["advisory lock"]
    cross_volume_rename_fallback["クロスボリュームのrenameフォールバック(コピー+削除)"]
    smb_share_file_handoff["共有フォルダ(SMB)越しのファイル連携"]
    rename_fails_on_open_handle["renameが開いているだけで失敗する"]
    file_timestamp_unreliability["ファイルタイムスタンプの不確実性"]
    periodic_directory_listing["定期的なディレクトリ列挙"]
    change_notification_loss["変更通知の取りこぼし"]
    file_handoff_protocol -->|"利用する"| atomic_claim
    file_handoff_protocol -->|"利用する"| temp_then_rename_publish
    file_handoff_protocol -->|"利用する"| done_manifest_file
    file_handoff_protocol -->|"利用する"| lock_file_lease
    file_handoff_protocol -->|"利用する"| idempotent_processing
    file_handoff_protocol -.->|"利用する"| os_file_lock
    atomic_claim -.->|"利用する"| atomic_creation
    atomic_claim -->|"防止する"| duplicate_processing
    exists_then_create_antipattern -->|"原因になり得る"| duplicate_processing
    atomic_claim -->|"推奨される対応"| exists_then_create_antipattern
    atomic_creation -->|"推奨される対応"| exists_then_create_antipattern
    direct_final_write_antipattern -->|"原因になり得る"| partial_write_read
    temp_then_rename_publish -->|"防止する"| partial_write_read
    size_stability_completion_check -.->|"原因になり得る"| partial_write_read
    done_manifest_file -->|"推奨される対応"| size_stability_completion_check
    shared_file_mutual_update_antipattern -->|"原因になり得る"| duplicate_processing
    idempotent_processing -->|"推奨される対応"| duplicate_processing
    lock_file_lease -->|"推奨される対応"| stale_lock
    lock_file_lease -->|"前提とする"| atomic_creation
    os_file_lock -->|"利用する"| byte_range_lock
    os_file_lock -.->|"軽減する"| duplicate_processing
    os_file_lock -->|"用いるのは非推奨"| heterogeneous_system_integration
    advisory_lock -.->|"用いるのは非推奨"| heterogeneous_system_integration
    temp_then_rename_publish -.->|"両立しない"| cross_volume_rename_fallback
    smb_share_file_handoff -.->|"原因になり得る"| cross_volume_rename_fallback
    smb_share_file_handoff -.->|"原因になり得る"| rename_fails_on_open_handle
    done_manifest_file -->|"推奨される対応"| file_timestamp_unreliability
    periodic_directory_listing -->|"推奨される対応"| change_notification_loss
    smb_share_file_handoff -.->|"原因になり得る"| change_notification_loss

概念間の関係(全29件)

図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。

受け渡しプロトコルは原子的claimを利用します。受け渡しプロトコルは、複数ワーカーが同じ入力を同時に処理しないよう原子的claimを構成要素として使う / 確度: 確立した関係 / 確認日: 2026-08-01 出典
受け渡しプロトコルはtemp -> close -> rename/replaceでの公開を利用します。受け渡しプロトコルは、書き込み途中のファイルを読ませないためにtemp->close->rename/replaceでの公開を構成要素として使う / 確度: 確立した関係 / 確認日: 2026-08-01 出典
受け渡しプロトコルはdone/manifestファイルを利用します。受け渡しプロトコルは、完了をタイムスタンプやサイズで推測せず明示するためにdone/manifestファイルを構成要素として使う / 確度: 確立した関係 / 確認日: 2026-08-01 出典
受け渡しプロトコルはlease化したlock fileを利用します。受け渡しプロトコルは、補助的な排他手段としてlease化したlock fileを構成要素として使う / 確度: 確立した関係 / 確認日: 2026-08-01 出典
受け渡しプロトコルはidempotency(冪等性)を前提にした処理を利用します。受け渡しプロトコルは、排他が破れた場合の最後の受け皿としてidempotencyを前提にした処理を構成要素として使う / 確度: 確立した関係 / 確認日: 2026-08-01 出典
受け渡しプロトコルはOSファイルロック(OSロック)を利用します。同一アプリ群・同一前提の参加者だけで動く場合、受け渡しプロトコルは補助手段としてOSファイルロックも使う(異種システム連携では前提が崩れるため使えない) / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
原子的claimは原子的作成(CreateNew / O_CREAT|O_EXCL)を利用します。renameではなくファイル作成そのもので原子性を確保する場合、原子的claimは.NETのFileMode.CreateNew系やPOSIXのO_CREAT|O_EXCLによる原子的作成でも実現できる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
原子的claimは二重処理(二重計上・二重送信・更新の消失)を防ぎます。incomingからprocessing/<worker>/へのrenameが成功したワーカーだけを所有者にすることで、複数ワーカーによる同一ファイルの二重処理を防ぐ / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Exists->Createの二段階チェックは二重処理(二重計上・二重送信・更新の消失)の原因になることがあります。有無の確認とファイル作成が別操作になっているため、間に他プロセスが割り込んで同じファイルを両方が処理してしまう / 確度: 確立した関係 / 確認日: 2026-08-01 出典
原子的claimはExists->Createの二段階チェックに対する本記事の推奨です。Exists->Createの二段階チェックが抱える競合問題に対し、本記事はrenameによる原子的claimを推奨している / 確度: 確立した関係 / 確認日: 2026-08-01 出典
原子的作成(CreateNew / O_CREAT|O_EXCL)はExists->Createの二段階チェックに対する本記事の推奨です。Exists->Createの二段階チェックが抱える競合問題に対し、本記事はFileMode.CreateNew系やO_CREAT|O_EXCLによる原子的作成も推奨している / 確度: 確立した関係 / 確認日: 2026-08-01 出典
最終ファイル名への直接書き込みは書き込み途中ファイルの読み込み事故の原因になることがあります。最終ファイル名に直接書き始めると、受信側がその名前を検知した時点でまだ書き込み中の内容を読んでしまう / 確度: 確立した関係 / 確認日: 2026-08-01 出典
temp -> close -> rename/replaceでの公開は書き込み途中ファイルの読み込み事故を防ぎます。生成中のファイルをtemp名に閉じ込め、closeしてからfinal名にrenameすることで、final名が見えた時点では内容が完成済みという約束を作る / 確度: 確立した関係 / 確認日: 2026-08-01 出典
ファイルサイズ安定待ちによる完了判定は書き込み途中ファイルの読み込み事故の原因になることがあります。ファイルサイズが一定時間変化しないことを完了とみなす判定は、ネットワーク越しのコピーの一時停止などで容易に完了と誤判定し、読み込み再開時に不完全な内容を読ませ得る / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
done/manifestファイルはファイルサイズ安定待ちによる完了判定に対する本記事の推奨です。完了をサイズの安定で推測する代わりに、done/manifestファイルで完了を明示することを本記事は推奨している / 確度: 確立した関係 / 確認日: 2026-08-01 出典
共有ファイルの相互更新アンチパターンは二重処理(二重計上・二重送信・更新の消失)の原因になることがあります。1つのstatus.csvやcounter.jsonを複数プロセスが読んで更新すると、後から書いた側の更新で先の更新が消える / 確度: 確立した関係 / 確認日: 2026-08-01 出典
idempotency(冪等性)を前提にした処理は二重処理(二重計上・二重送信・更新の消失)に対する本記事の推奨です。排他が完全に守られない場合でも、同じ入力の再処理が結果を変えないようにしておくことを本記事は推奨している / 確度: 確立した関係 / 確認日: 2026-08-01 出典
lease化したlock fileはstale lockに対する本記事の推奨です。ownerId・expiresAt・heartbeatAtを持つlease形式のlock fileにすることで、持ち主不明のまま残るstale lockへの対処を本記事は推奨している / 確度: 確立した関係 / 確認日: 2026-08-01 出典
lease化したlock fileは原子的作成(CreateNew / O_CREAT|O_EXCL)を前提とします。lease化したlock fileも、作成自体は原子的に行う必要がある / 確度: 確立した関係 / 確認日: 2026-08-01 出典
OSファイルロック(OSロック)はbyte-range lock(範囲ロック)を利用します。OSファイルロックの具体例として、Windowsのbyte-range lock(LockFileEx / FileStream.Lock)がある / 確度: 確立した関係 / 確認日: 2026-08-01 出典
OSファイルロック(OSロック)は二重処理(二重計上・二重送信・更新の消失)を軽減します。OSファイルロックは、同一アプリ群・同一前提で動く参加者同士の間でだけ、同一ファイルの同時処理を軽減できる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
OSファイルロック(OSロック)を異種システム連携に用いることは推奨されません。OSロックは全参加者が同じ約束で動くときだけ効くため、異種システム連携でロックAPI単体に完了通知や所有権の設計まで背負わせるのは推奨されない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
advisory lockを異種システム連携に用いることは推奨されません。Linuxのflockはadvisory lockなので、約束を無視して読み書きするプログラムも書けてしまい、異種システム連携でこれだけに頼るのは推奨されない / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
temp -> close -> rename/replaceでの公開はクロスボリュームのrenameフォールバック(コピー+削除)と両立しません。tempとfinal(共有をまたぐ場合など)が別ボリュームにあると、rename/MoveFileExがコピーと削除で移動を代替し、原子的な公開という前提が崩れる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
共有フォルダ(SMB)越しのファイル連携はクロスボリュームのrenameフォールバック(コピー+削除)の原因になることがあります。共有フォルダ越しの連携で、tempとfinal(またはincomingとprocessing)を別の共有に置くと、rename/MoveFileExがコピーと削除に代替され得る / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
共有フォルダ(SMB)越しのファイル連携はrenameが開いているだけで失敗するの原因になることがあります。共有フォルダにはウイルス対策・検索インデクサー・他拠点のクライアントなど把握していない相手がアクセスするため、publishやclaimのrenameが単に開かれているだけで失敗し得る / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
done/manifestファイルはファイルタイムスタンプの不確実性に対する本記事の推奨です。書き込み用ハンドルを閉じるまで最終更新時刻が完全には更新されず、ファイルシステムやSMB越しの時計依存で粒度もずれるため、完了判定を時刻ではなくdone/manifestで行うことを本記事は推奨している / 確度: 確立した関係 / 確認日: 2026-08-01 出典
定期的なディレクトリ列挙は変更通知の取りこぼしに対する本記事の推奨です。共有フォルダの監視をイベント通知だけに頼ると変更を取りこぼすことがあるため、定期的なディレクトリ列挙の併用を本記事は推奨している / 確度: 確立した関係 / 確認日: 2026-08-01 出典
共有フォルダ(SMB)越しのファイル連携は変更通知の取りこぼしの原因になることがあります。共有フォルダ越しの連携では、変更通知イベントの取りこぼしが起こり得る / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典

主要概念の定義

受け渡しプロトコル: ファイル連携において、いつ読んでよいか・誰が処理権を持つか・失敗時にどう回復するかを明示的に設計する取り決め。OSロックだけに頼らず、temp->rename公開・原子的claim・done/manifest・lease化したlock file・idempotencyを組み合わせて構成する。
原子的claim: 複数ワーカーが同じ入力ファイルを同時に処理しないよう、処理権の確保を1操作で行うこと。incomingからprocessing/<worker>/へのrenameのほか、FileMode.CreateNewやO_CREAT|O_EXCLによる原子的なファイル作成でも実現できる。
temp -> close -> rename/replaceでの公開: 生成中のファイルをtemp名に閉じ込め、closeしたあとで同一ディレクトリ・同一ボリューム上のfinal名へrename/replaceする、書き込み途中のファイルを読ませないための公開パターン。
Exists->Createの二段階チェック: ファイルの有無を確認してから作成する、確認と確保が別操作になった実装。間に他プロセスが割り込めるため排他にならない。
原子的作成(CreateNew / O_CREAT|O_EXCL): 「無ければ作る」を1操作で行うファイル作成方法。.NETのFileMode.CreateNew系やPOSIXのO_CREAT | O_EXCLで実現し、確認と確保が分離した二段階チェックの隙間を無くす。
最終ファイル名への直接書き込み: 受信側が「その名前が見えたら読んでよい」と解釈しているのに、送信側が最終ファイル名に直接書き始めてしまう実装。書き込み途中の内容がそのまま見えてしまう。
ファイルサイズ安定待ちによる完了判定: ファイルサイズが一定時間変化しないことをもって転送完了とみなす判定方法。ネットワーク越しのコピーの一時停止などで容易に誤判定する。
done/manifestファイル: 本体ファイルとは別に、ファイル名・サイズ・ハッシュ・レコード数・idempotency keyなどを記録し、受信側が完全性を検証するための説明ファイル。doneファイルはその最小版。
共有ファイルの相互更新アンチパターン: 1つのstatus.csvやcounter.jsonを複数プロセスが読み書きして状態を共有しようとする設計。読み取り後の更新がタイミングによって互いに上書きされ、後に書いた側で先の更新が消える。
idempotency(冪等性)を前提にした処理: 同じ入力をもう一度処理しても結果が変わらない性質を前提に、排他が破れた場合の二重実行を処理済み台帳への記録で吸収する設計。
lease化したlock file: ownerId・host・pid・acquiredAt・expiresAt・heartbeatAtを持つ、有効期限付きの所有情報として実装するlock file。更新停止をstale判定の材料にし、削除は原則として作成者だけが行う。
OSファイルロック(OSロック): advisory lockやbyte-range lockなど、ファイルシステムやOSが提供する排他制御の総称。同一アプリ群・同一前提の中では有効だが、受け渡しプロトコルの代わりにはならない。
advisory lock: 参加者全員が約束を守る前提でだけ効くロック。OSが強制しないため、無視して読み書きするプログラムも書ける。Linuxのflockが該当する。
共有フォルダ(SMB)越しのファイル連携: SMB共有フォルダを介してtemp->rename公開やclaimを行う運用。同一共有内では原子性が保たれる一方、ボリュームをまたぐ移動・他プロセスによる開放中の失敗・タイムスタンプの不確実性・変更通知の取りこぼしが追加のリスクになる。
定期的なディレクトリ列挙: イベント通知だけに頼らず、一定間隔でディレクトリを列挙して未検知のファイルを拾う監視方式。

機械可読データ

JSON-LD / Turtle ── この記事の知識グラフ全体
概念一覧 / 語彙(述語)の定義

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。