我编写了一个读取 NTFS 索引和日志的程序，类似于此处描述的内容：http:
//ejrh.wordpress.com/2012/07/06/using-the-ntfs-journal-for-backups/
和它工作得很好。
除了正常的日志事件之外USN_REASON_CLOSE，USN_REASON_FILE_CREATE我USN_REASON_FILE_DELETE还收到了一个有原因的事件USN_REASON_HARD_LINK_CHANGE。我希望能够根据此事件更新目录索引，但我找不到任何有关它的信息。唯一的文件是：
NTFS 文件系统硬链接被添加到文件或目录中或从文件或目录中删除。NTFS 文件系统硬链接，类似于 POSIX 硬链接，是可以看到相同文件或目录的多个目录条目之一。
这是什么意思？硬链接是在哪里创建的？还是被删除了？我如何获得有关所发生事情的更多信息？
我知道这是古老的，但我在研究相关问题时偶然发现了这一点。以下是我的发现：硬链接是阅读 USN 时的一个复杂因素。您可以通过通过已创建的任何硬链接进行的更改来获取描述对单个文件参考号的更改的日志条目。通常，对于原始问题，硬链接是可以访问单个文件的替代目录条目。因此，每个链接都共享所有文件的特征（名称和父文件参考号除外）。从技术上讲，您无法分辨哪个条目是原始条目，哪个条目是链接。
确实存在细微差别，如果您查询主文件表（使用 DeviceIOControl 和 Fsctl_Enum_Usn_Data），它就会显现出来。无论存在多少链接，查询都将只返回一个代表文件。您可以使用 NtQueryInformationFile 查询链接，查询 FILE_HARD_LINK_INFORMATION。我认为 MFT 查询返回的条目是主条目，NtQueryInformationFile 返回的项目是链接......但是，主条目可以被删除，其中一个链接将被提升......所以这只是一个家务思想还有一点。
请注意，当硬链接之一被移动或重命名时会出现问题。在这种情况下，重命名或移动的日志条目反映了受影响链接的文件名和父文件参考号。如果您只要求汇总“关闭”记录，就会出现问题。在这种情况下，您将永远看不到 USN_REASON_RENAME_OLD_NAME 记录...因为该 USN 条目永远不会获得与其关联的 REASON_CLOSE。如果没有这个花絮，您将无法轻松确定哪个链接的名称或位置已更改。您必须在 Read_Usn_Journal_Data_V0 中将 ReadOnlyOnClose 设置为 0 来读取 usn。这是一个更健谈的查询，但没有它，您无法准确地将更改与一个链接或另一个链接相关联。
与 USN 一样，我希望您需要进行一些试验和错误才能使其正常工作。我希望这些观察/猜测可能会有所帮助：
当文件的最后一个硬链接被删除时，文件被删除；因此，如果最后一个硬链接已被删除，您应该会看到 USN_REASON_FILE_DELETE 而不是 USN_REASON_HARD_LINK_CHANGE。我相信每个参考编号指的是一个文件（或目录，但 NTFS 不支持多个指向目录 AFAIK 的硬链接）而不是一个硬链接。所以在事件被记录之后，至少，文件引用号应该仍然有效，并且指向文件的另一个名称。
如果该文件还存在，您可以通过参考号查找并使用FindFirstFileNameW和朋友查找当前链接。将此与有问题的事件记录以及任何相关的后续事件进行比较应该可以为您提供足够的信息，尽管如果同一文件的多个硬链接被删除和/或创建，您可能无法重建发生这种情况的顺序，并且如果您没有足够的关于文件系统先前状态的信息，您可能无法识别已删除的硬链接。我不知道这对你是否重要。
如果文件不再存在，您应该仍然能够通过删除它的 USN 记录来识别它。同样，考虑到所有相关事件，并有足够的关于先前状态的信息，你应该能够重建大部分发生的事情，如果不是顺序的话。
有一些希望我们可以做得比这更好：事件记录中的文件名和/或 ParentFileReference 编号可能指的是创建或删除的硬链接，而不是指向文件的任意链接。在这种情况下，您将获得有关事件序列的所有相关信息，除了任何特定事件是创建还是删除，您应该能够通过查看文件的当前状态并向后工作来解决记录。
我假设您已经在附近寻找可能包含其他信息的更改记录？例如，在创建硬链接时没有生成 USN_REASON_RENAME_NEW_NAME 记录，或者在删除硬链接时没有生成 USN_REASON_RENAME_OLD_NAME 记录？还是成对的 USN_REASON_HARD_LINK_CHANGE 记录，一条用于文件，一条用于包含受影响的文件硬链接的目录？（一厢情愿，我希望，但看看不会有坏处！）
出于测试目的，您可以使用该mklink命令创建硬链接。