我编写了一个读取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 的活动。我希望能够根据此事件更新目录索引，但我找不到任何有关它的信息。 only documentation is：
在文件中添加或删除NTFS文件系统硬链接 目录。一个NTFS文件系统硬链接，类似于POSIX硬盘 link，是查看同一文件或的几个目录条目之一 。目录
这是什么意思？硬链接在哪里创建？还是被删除了？如何获得有关发生的事情的更多信息？
答案 0 :(得分：1)
我知道这很古老，但我在研究相关问题时偶然发现了这一点。这就是我发现的：在阅读USN时，硬链接是一个复杂的因素。您可以通过通过任何已创建的硬链接进行的更改来获取描述单个文件引用号的更改的日记条目。通常，对于原始问题，硬链接是可以访问单个文件的备用目录条目。因此，每个链接共享所有文件的特征（名称和父文件引用号除外）。从技术上讲，您无法分辨哪个条目是原始条目，哪个条目是链接。
确实存在细微差别，如果您查询主文件表（使用DeviceIOControl和Fsctl_Enum_Usn_Data），则会显示。无论存在多少链接，查询将仅返回单个代表性文件。您可以使用NtQueryInformationFile查询链接，查询FILE_HARD_LINK_INFORMATION。我认为MFT查询作为主条目返回的条目和NtQueryInformationFile返回的项目作为链接...但是，主条目可以被删除，其中一个链接将被提升......所以它是＃s只有看家的想法和其他一点点。
请注意，在移动或重命名其中一个硬链接时会出现问题。在这种情况下，重命名或移动的日志条目反映了受影响链接的文件名和父文件引用号。如果你只要求摘要＆＃34; on-close＆＃34;记录。在这种情况下，您无法看到USN_REASON_RENAME_OLD_NAME记录...因为该USN条目永远不会获得与之关联的关联REASON_CLOSE。如果没有这个消息，您将无法轻松确定哪个链接的名称或位置已更改。您必须在Read_Usn_Journal_Data_V0中将ReadOnlyOnClose设置为0来读取usn。这是一个更加可怕的查询，但如果没有它，您就无法准确地将更改与一个链接或另一个链接相关联。
答案 1 :(得分：0)
与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命令创建硬链接。