知識マップ: FileSystemWatcher実務ガイド - 取りこぼしと重複対策

記事「FileSystemWatcher実務ガイド - 取りこぼしと重複対策」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

この記事は、FileSystemWatcherのCreated/Changedイベントを完了通知として扱う誤りや、内部バッファのoverflowによる通知の取りこぼし、イベント列から状態を復元しようとする設計を避け、通知はすべて1種類の再スキャン要求に畳んでfull rescanで現物を確認する設計を提案する。完了は送信側がtemp->rename/done・manifestで明示し、受信側は再スキャンで見つけたready候補に対して原子的claimを取り、複数回見に行くことを前提にidempotencyで受け止める。常時起動できない、あるいは取りこぼしが許されない要件にはUSNチェンジジャーナルという選択肢もあると位置付けている。

FileSystemWatcher実務ガイドの知識マップFileSystemWatcherの通知が完了通知ではなく変化の気配に過ぎないこと、通知を再スキャン要求へ畳んでfull rescanとclaimと組み合わせること、内部バッファのoverflowによる通知の取りこぼしとUSNチェンジジャーナルという代替の関係を示す図原因になり得る利用する推奨される対応推奨される対応用いるのは非推奨原因になり得る原因になり得る原因になり得る推奨される対応利用する利用する推奨される対応推奨される対応推奨される対応原因になり得る防止する利用する利用する推奨される対応より先に行うべきより先に行うべき原因になり得る軽減する推奨される対応前提とする前提とするFileSystemWatcherfull rescan(ディレクトリの全体再走査)内部バッファのoverflowによる通知の取りこぼし定期的なディレクトリ列挙変更通知の取りこぼしInternalBufferSizeの調整Errorイベントをログだけ出して無視するアンチパターンCreatedを完了通知だと誤解する書き込み途中ファイルの読み込み事故送信側での完了条件の明示temp -> close -> rename/replaceでの公開done/manifestファイル通知を再スキャン要求に畳むChangedの回数・順序を信じるアンチパターンイベント列から状態を復元しようとするアンチパターン二重処理(二重計上・二重送信・更新の消失)原子的claimbundle(連携単位のディレクトリ)idempotency(冪等性)を前提にした処理watcher停止中の変更取りこぼしUSNジャーナル(変更ジャーナル)NTFS管理者権限

概念間の関係(全26件)

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

主要概念の定義

FileSystemWatcher
.NETが提供する、ファイル・ディレクトリの作成・変更・削除・名前変更をイベントで通知するAPI。ディレクトリ通知はアプリが動いている間しか受け取れず、内部バッファのoverflowで個別通知を取りこぼすことがある。
full rescan(ディレクトリの全体再走査)
個々の変更イベントを当てにせず、監視対象ディレクトリを一から列挙し直して処理してよい対象を洗い直すこと。起動時・Error受信時・watcher再生成直後・定期的な保険として実行する。
InternalBufferSizeの調整
FileSystemWatcherの内部バッファサイズを既定の8192バイトから64KBまでの範囲で調整すること。non-paged memoryを使うため増やすほど気軽ではなく、バーストがその上限を超えれば依然として取りこぼす。
Errorイベントをログだけ出して無視するアンチパターン
FileSystemWatcherのErrorイベント(buffer overflowや監視継続失敗を示す)をログ出力のみで済ませ、full rescanなどの回復処理を行わない設計。
Createdを完了通知だと誤解する
FileSystemWatcherのCreatedイベントを「名前が見えた」以上の「もう読んでよい」という保証だと誤解して読み込みを始めてしまう誤り。コピーや転送では作成直後にCreatedが飛び、そのあとに1回以上のChangedが続くことがある。
送信側での完了条件の明示
受信側でFileSystemWatcherの完了判定を頑張るのではなく、送信側がtemp名での書き込み・close・rename/replace・done/manifestの配置で完了を明示するプロトコル設計。
通知を再スキャン要求に畳む
Created/Changed/Deleted/Renamed/Error/startupなど複数種類の通知を、実処理に直結させず「見に行け」という単一の再スキャン要求信号に統合すること。バースト時はまとめてから1回の走査を1本のworkerで行う。
Changedの回数・順序を信じるアンチパターン
Changedイベントが1回だけ、決まった順序で来るという前提を置く設計。移動や保存の1操作でも複数イベントに分かれ、ウイルス対策やインデクサが触った分まで拾われるため、この前提は崩れる。
原子的claim
複数ワーカーが同じ入力ファイルを同時に処理しないよう、処理権の確保を1操作で行うこと。incomingからprocessing/<worker>/へのrenameのほか、FileMode.CreateNewやO_CREAT|O_EXCLによる原子的なファイル作成でも実現できる。
bundle(連携単位のディレクトリ)
本体データ・manifest・補助ファイルを1つのディレクトリにまとめた、1件分の連携単位。ディレクトリごと1回のrenameでclaimできる。
idempotency(冪等性)を前提にした処理
同じ入力をもう一度処理しても結果が変わらない性質を前提に、排他が破れた場合の二重実行を処理済み台帳への記録で吸収する設計。
USNジャーナル(変更ジャーナル)
ボリューム内のファイル・ディレクトリへの変更のたびに、変更内容と対象の名前を記録する台帳。バックアップや検索インデクサーが全走査なしで差分を把握するために使う。

機械可読データ

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