この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。Microsoft LearnのFileSystemWatcher仕様を確認し、重複event・debounce・取りこぼしを別問題として観察するTRYに整理しています。検証ステータス：📘 .NET公式仕様確認済み・PowerShell実機未確認
今回の成功条件：同じファイルに短時間で複数eventが来ても、後続処理候補を1回へまとめられれば成功。
FileSystemWatcherは「1回保存したらChangedが必ず1回」とは限りません。Microsoftも一般的なfile system操作で複数eventが発生し得ることを説明しています。
Smoke Test：まず生eventを見る
$dir = Join-Path $env:TEMP 'papanda-watch'
New-Item -ItemType Directory -Force $dir | Out-Null
$w = [IO.FileSystemWatcher]::new($dir)
$w.EnableRaisingEvents = $true
$sub = Register-ObjectEvent $w Changed -Action {
"[EVENT] $([DateTime]::Now.ToString('HH:mm:ss.fff')) $($Event.SourceEventArgs.Name)"
}
"A" | Set-Content (Join-Path $dir 'demo.txt')
"B" | Add-Content (Join-Path $dir 'demo.txt')
Start-Sleep 1
Unregister-Event -SourceIdentifier $sub.Name -ErrorAction SilentlyContinue
$w.Dispose()
ここを見る
[EVENT]が何行出るかを見ます。環境によってevent数は変わり得るので、「2回出るはず」のように固定しません。重複し得ること自体を設計条件にするのが重要です。
debounceの考え方
flowchart LR E1[event] --> T[タイマーを更新] E2[event] --> T E3[event] --> T T -->|静かな時間が経過| J[後続処理を1回]
debounceは短時間の連続eventを「静かになるまで待って1回へ寄せる」方法です。ただし、これは取りこぼし対策ではありません。FileSystemWatcherの内部buffer overflowやprocess停止中の変更まで保証する永続queueではありません。
1か所変えてみる
待ち時間を100msと1000msで比べると、まとめやすさと反応速度のtrade-offが見えます。業務では「ファイルコピーが終わる前に処理を始めない」ため、サイズが一定になったか、openできるか等のready判定も別に必要です。
仕事で使うなら
共有フォルダへ届くCSVの自動取込、スキャンPDFの後処理、ログ監視などへ応用できます。事務業務なら「ファイルが置かれたら即処理」ではなく、event受信 → debounce → file ready確認 → 処理済みID記録まで作ると事故が減ります。
失敗・境界
debounceしてもevent欠落は復元できません。
同名fileの上書き・rename・大量投入を別ケースで試します。
後続処理は冪等にし、同じfileを2回受けても壊れない設計にします。
watcher/event subscriptionはfinally等で後始末します。
