估计NTFS卷上的USNlogging数

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

有没有一种方法可以在运行之前估计卷上的logging数量,因此可以显示进度?

我猜测整个卷的USN数据是从MFT生成的,每个文件一个logging(大约)。 因此,估计MFT中活动文件数量的一种方法是可行的。

您可以使用FSCTL_GET_NTFS_VOLUME_DATA获取MFT的字节长度。 如果将其与选定的代表性卷上的记录数进行比较,则可以估算单个MFT记录的平均长度,并使用此值计算特定卷上记录数的估计值。

因为MFT包含(例如)每个文件的安全信息,所以平均长度在音量之间会有很大的差异,所以我认为你只能得到数量级的准确性,但是在大多数情况下。

另一种方法是假定文件参考数字线性增加,这大致正确。 您可以使用FSCTL_ENUM_USN_DATA来查明是否有任何文件的参考号超过了特定的猜测值; 你需要不超过128个猜测来确定实际的最大参考数字。 那么在任何给定的点上,至少会给你一个0到100之间的完整比例,这不会是完全统一的,但是进度条从来就不是。 🙂

额外:

仔细观察,在Windows 7 x64上,FSCTL_ENUM_USN_DATA(在第一个USN_RECORD结构之前返回的四字)返回的“next id”字段毕竟不是文件引用号,而是文件记录段号。 因此,如您所见,返回的最后一个id号乘以BytesPerFileRecordSegment(1024),等于MftValidDataLength。

文件参考号似乎由两部分组成。 低六个字节包含文件记录段号码。 从每个请求返回的第一条记录始终有一个FRN,其段号与输入到StartFileReferenceNumber中的“next id”相同,除了StartFileReferenceNumber为零时的第一个调用。 上面的两个字节包含未指定的附加信息,从不为零。

似乎FSCTL_ENUM_USN_DATA接受文件记录段号(在这种情况下,前两个字节为零) 文件引用号(在这种情况下,前两个字节为非零)。

奇怪的是,我找不到两个具有相同记录段号的记录。 这表明每个文件记录在MFT中至少使用1K,这似乎不合理。

无论如何,结果是,将BytesPerFileRecordSegment乘以“next id”并将其除以MftValidDataLength以获得完成的百分比可能是明智的,只要你适度地应对,如果这返回一个无意义的结果。