问题标签 [usn]

首次使用 USN 日志时，必须使用 FSCTL_ENUM_USN_DATA 控制代码枚举该卷的整个 USN 记录集。这通常是一个漫长的操作。

有没有办法在运行之前估计卷上的记录数，以便显示进度？

我猜整个卷的 USN 数据是从 MFT 生成的，每个文件有一条记录（大约）。因此，也许一种估计 MFT 中活动文件数量的方法会起作用。

各位程序员好。

我正在尝试使用WinIoCtl函数转储NTFS分区的 USN 日志的内容。我有 *USN_JOURNAL_DATA* 结构，它告诉我它的最大大小为 512 MB。我已经将它与fsutil所说的进行了比较，它的价值是相同的。

现在我必须将每个条目读入 *USN_RECORD* 结构。我在一个从 0 开始的 for 循环中执行此操作，并以 4096（簇大小）为增量达到日志的最大大小。我在相同大小的缓冲区中读取每个 4096 字节，并从中读取所有 USN_RECORD 结构。

一切都很好，文件名正确，时间戳，原因，一切，除了我似乎错过了一些最近的记录。我在分区上创建了一个新文件，在其中写入了一些内容，然后删除了该文件。我再次运行该应用程序并没有出现记录。我发现只有当我继续阅读超过期刊的最大尺寸时才会出现记录。怎么可能？

目前我正在从期刊数据的开头读取到最大大小+分配增量（两者都是存储在 *USN_JOURNAL_DATA* 结构中的值），我不认为它是正确的，我很难找到彻底与此相关的信息。

有人可以解释一下吗？USN 日志周围是否有类似于MFT工作方式的缓冲区（这意味着当其他文件需要磁盘空间时，它的大小减半）？

我究竟做错了什么？

如果我有一个目录，其中有几个硬链接都指向目录外的文件，对其中一个硬链接的更改会影响与该目录关联的 USN 日志，还是会影响包含实际文件的原始目录的 USN 日志哪些硬链接在创建时链接？

在我的备份应用程序中，我使用USN 日志来检查卷的更改。默认情况下，USN 是禁用还是启用？在此链接（旧文章）中提到“默认情况下，NTFS 卷将禁用其更改日志”。我在任何网站上都没有得到太多关于它的信息。它真的在 NTFS 驱动器上被禁用还是基于操作系统？这对我很重要，因为我在我的应用程序中使用它。

在我的备份应用程序中，我使用 USN 日志来检查卷的更改。在微软网站上，它提到像 USN 有一个最大大小，并且文件得到完整记录被删除。

MaximumSize 是更改日志的目标最大大小（以字节为单位）。更改日志可以增长到大于此值，但在 NTFS 文件系统检查点，NTFS 文件系统检查日志并在其大小超过 MaximumSize 的值加上 AllocationDelta 的值时修剪它。（在 NTFS 文件系统检查点，操作系统将记录写入 NTFS 文件系统日志文件，允许 NTFS 文件系统确定从故障中恢复所需的处理。）

那么当日志满了的时候会发生什么呢？所有记录都会被删除吗？还是只有它会删除最旧的记录并为新记录创建一个条目？我如何处理美国期刊大小的完整案例？

我正在尝试找到一种方法，让系统在有新条目时告诉我，USN Change Journal以跟踪对NTFS卷上的文件和目录所做的修改（Server 2008/2012）。

这样我就不必不断地轮询日志，并且可以让我的线程休眠，直到有新的更改事件时收到通知。

然而，还有这样的中断吗？

该FSCTL_QUERY_USN_JOURNAL函数没有特别提到中断（事件、通知），我也无法找到另一种方法来使用不太密集的轮询和比较技术来实现这一点。

我不是一个铁杆程序员，所以可能有更简单的方法可以将这些函数与我不知道的中断联系起来。

我是否可以找出 USN 更改日志的存储位置并使用另一个可以生成和中断更改的进程查看该文件？

https://msdn.microsoft.com/en-us/library/aa365729(v=vs.85).aspx

我正在使用几个磁盘/分区（C:、D:、E:、F: 等）的 NTFS MasterFileTable / USN 日志，并且我想为每个文件/目录使用唯一的 ID。

当我阅读USN_RECORD（也称为 PUSN_RECORD）时，有这个 int64：

这是一个唯一的文件/目录标识符，至少在当前分区中是唯一的。

但可能会发生碰撞：

• C 中的文件：可能有 FileReferenceNumber 1932847
• D: 中的另一个文件也可能有 FileReferenceNumber 1932847！

我想避免不得不使用这样一个大的东西int128（这将是FileReferenceNumber驱动器号 C:、D:、E:、...、Z: 的 64 位 + 5 位）。

我还想避免使用一对(char DriveLetter, DWORDLONG FileReferenceNumber)来识别计算机中的文件。

如何使用 64 位 int 编码FileReferenceNumber+ 盘符？

是否有可能因为FileReferenceNumber有一些空闲的未使用位？

如果不是，您将如何处理？

在进行 USN 日志/NTFS MFT 文件枚举之前

我想知道文件/目录的数量（“保留”一个 std::vector:v.reserve(...)以及其他原因）。

我FSCTL_QUERY_USN_JOURNAL之前考虑过使用，它提供了USN_JOURNAL_DATA_V0有关音量的包含信息。

不幸的是，FirstUsn不要提供此信息。即使我的卷上有 100k 个文件，例如可以是 1000 万个，所以它没有给出正确的数量级。NextUsnMaxUsnNextUsn

如何在执行 FSCTL_ENUM_USN_DATA 之前获取文件/目录的数量？

我正在使用此代码来填充磁盘上所有文件的数据库：

一旦循环完成，数据库就被成功填充。

但是如何继续（作为后台任务）实时监控文件更改/删除？（例如：显示MessageBox()“文件 readme.txt 已重命名。”）

我是否应该每 1 秒重新启动一次这样的循环，其中med.StartFileReferenceNumber= 以前见过的最高 FileReferenceNumber？

注意：我有点不愿意每 1 秒启动一次此代码（99% 的时间，白费）。相反，每 10 秒执行一次可以避免使用这么多资源，但是在检测到更改之前会有延迟，而我确实知道一些没有这种延迟的索引软件。

注意2：我阅读了如何仅检测卷上已删除、更改和创建的文件？但主要答案的目的是运行一次，而不是一直在后台运行。

注意 3：我查看了 Microsoft Keeping an Eye on Your NTFS Drives 中的这个有用的代码示例：Windows 2000 Change Journal Explained。

注意4：我是否应该保留FSCTL_ENUM_USN_DATA用于初始数据库加载，然后使用FSCTL_READ_USN_JOURNAL代替？

注意5：ReadDirectoryChangesW或者FindNextChangeNotification（前者给出了通知中更改的完整路径，后者没有）不能真正使用，因为它不会给出FileReferenceNumber已删除文件的 （必须打开文件并使用NtQueryInformationFile才能获取它；但这对于已删除的文件是不可能的）；并且 FileReferenceNumber 是更新文件数据库所必需的（文件数据库使用以 FileReferenceNumbers 作为键的映射/字典）。

我正在使用FSCTL_ENUM_USN_DATA枚举 NTFS MFT，以便我可以基于 USN_RECORD FileReferenceNumbers 构建目录数据库。我正在构建这个数据库，以便我可以通过使用 NTFS USN 更改日志并读取 USN_RECORD（使用引用目录数据库的 FileReferenceNumber 和 ParentFileReferenceNumber）来监视 NTFS 驱动器上的文件更改。有关执行此操作的信息，请参见此处。

我的问题与 USN Record 版本有关。如果您看一下，USN_RECORD_V2支持的 FileReferenceNumbers (DWORDLONG) 数据类型与USN_RECORD_V3 (FILE_ID_128) 不同。这很好，如果 FSCTL_ENUM_USN_DATA 支持 USN_RECORD_V3。问题是在 Windows 10 中使用了 USN_RECORD_V3，而在 Windows 7 中使用了 USN_RECORD_V2。

FSCTL_ENUM_USN_DATA 将MFT_ENUM_DATA_V1或MFT_ENUM_DATA_V0作为其输入缓冲区。我假设 V1 支持 FILE_ID_128 FileReferenceNumbers，但事实证明这个假设是不正确的。似乎不支持 USN_RECORD_V3 及其关联的 FileReferenceNumber 数据类型。因此，在使用 USN_RECORD_V3 或更高版本的 Windows 版本上使用 NTFS 更改日志监视 NTFS 驱动器上的更改现在是一个大问题。

我找到了一个临时解决方案！在 Windows 10 上枚举 MFT 时，FSCTL_READ_ENUM_DATA 仅返回 USN_RECORD_V2，给出 DWORDLONG 类型的 FileReferenceNumbers。反过来，我被迫将这些 DWORDLONG FileReferenceNumbers 移位到 128 位缓冲区中，以便目录缓存与FSCTL_READ_USN_JOURNAL调用返回的 USN_RECORD_V3 匹配。

然而，我不禁觉得我错过了一些东西。有没有人对此问题有任何其他解决方案，或者可以采取任何替代方法？请记住，监视程序未运行时对驱动器所做的更改对于我的项目至关重要。