USN の場合と同様に、適切に機能させるには試行錯誤が必要になると思います。これらの観察/推測が役立つことを願っています:
ファイルへの最後のハード リンクが削除されると、そのファイルは削除されます。そのため、最後のハード リンクが削除されている場合は、USN_REASON_HARD_LINK_CHANGE ではなく USN_REASON_FILE_DELETE が表示されます。各参照番号は、ハードリンクではなく、ファイル（またはディレクトリですが、NTFSはディレクトリへの複数のハードリンクをサポートしていません）を参照していると思います。そのため、少なくともイベントが記録された直後は、ファイル参照番号は引き続き有効であり、ファイルの別の名前を指している必要があります。
ファイルがまだ存在する場合は、参照番号でFindFirstFileNameW検索し、友人と使用して現在のリンクを見つけることができます。これを問題のイベント レコードと関連するその後のイベントと比較すると、十分な情報が得られます。ファイル システムの以前の状態に関する十分な情報がない場合、削除されたハード リンクを特定できない場合があります。それがあなたにとって重要かどうかはわかりません。
ファイルが存在しなくなった場合でも、ファイルが削除された USN レコードによって識別できるはずです。繰り返しになりますが、関連するすべてのイベントを考慮に入れ、以前の状態に関する十分な情報があれば、順序ではないにしても、起こったことのほとんどを再構築できるはずです。
これよりもうまくいく可能性があります。イベント レコードのファイル名および/または ParentFileReference 番号は、ファイルへの任意のリンクではなく、作成または削除されたハード リンクを参照する可能性があります。この場合、特定のイベントが作成または削除であったかどうかを除いて、一連のイベントに関するすべての関連情報が得られます。これは、ファイルの現在の状態を調べて逆方向に作業することで解決できるはずです。記録。
追加情報が含まれている可能性のある近くの変更レコードを既に探していると思いますか? たとえば、ハード リンクが作成されたときに USN_REASON_RENAME_NEW_NAME レコードが生成されたり、ハード リンクが削除されたときに USN_REASON_RENAME_OLD_NAME レコードが生成されたりしませんか? または、USN_REASON_HARD_LINK_CHANGE レコードを対にして、1 つはファイル用、もう 1 つは影響を受けるファイルへのハード リンクを含むディレクトリ用ですか? （希望的観測だと思いますが、見て損はありません！）
テスト目的で、コマンドを使用してハード リンクを作成できますmklink。