為什麼 NTFS USN 變更日誌重設後，檔案監控應用程式會遺漏部分檔案變更？

你提到可以透過檢查 Windows 事件記錄，確認 NTFS USN 變更日誌是否曾經被刪除並重新建立。

請問你會優先檢查哪些特定的 Windows 事件記錄、事件來源或事件 ID，來確認是否發生過這類操作？你會如何區分 USN 變更日誌實際被刪除或重新建立的事件，以及其他與 NTFS 檔案系統相關的事件？

另外，如果在事件檢視器中找不到相關記錄，你還會使用哪些替代方法，進一步調查 USN 變更日誌是在何時以及因為什麼原因被重新建立？

您好，感谢您说明档案监控应用程序遇到的情况。

是的，删除并重新建立 NTFS USN 变更日志，可能会让监控应用程序无法读取先前记录的变更。 USN 日志记录的是档案变更及其原因，不是档案内容或完整的变更历史; 日志删除期间发生的变更也可能不会留下可供应用程序读取的记录。 Microsoft：USN 变更日志记录

查询目前日志状态

请以系统管理员身份开启命令提示字元，对应用程序监控的每个 NTFS 磁盘区执行：

fsutil USN Queryjournal C：

fsutil USN Queryjournal D：

请记录输出中的 Usn Journal ID、First Usn、Next Usn 和 Lowest Valid Usn，以及日志大小栏位。 此命令查询的是目前状态，不会变更日志。 Microsoft：fsutil usn

判断监控应用程序是否需要重新扫描

USN 日志有一个识别码（Usn Journal ID）。 应用程序应同时保存该识别码及最后处理的 USN，并在重新启动监控时与目前值比较。

• 如果目前的 Usn Journal ID 与应用程序保存的不同，代表日志识别码已变更或重新标记。 这表示旧检查点可能不再有效，但__单靠目前输出无法确认日志是由谁或何时重建的__。 若没有先前保存的识别码或应用程序记录，也无法只靠现在的查询结果证明过去曾重建日志。
• 如果应用程序保存的 USN 早于目前的 First Usn，它要读取的旧记录可能已被移除; 此时应用程序可能收到 ERROR_JOURNAL_ENTRY_DELETED。 日志大小达到上限后，NTFS 也可能移除较旧记录，因此即使识别码相同，落后太久的应用程序仍可能需要重新比对文件。 Microsoft：变更日志识别码; Microsoft：USN 日志读取资料

如果日志目前未启用，或正在删除，请先确认应用程序记录中的错误并查明日志状态; 删除进行中时，日志读取等作业可能回报 ERROR_JOURNAL_DELETE_IN_PROGRESS。

建议的复原方式

检查应用程序记录中的日志识别码、最后处理的 USN，以及上述错误码。 若识别码不符或检查点已落在可读范围之外，请依该应用程序厂商的指示执行完整扫描、重新索引或其他重新比对程序。 不要只把检查点直接设为目前的 Next Usn，否则可能跳过尚未盘点的变更。

排查期间请只使用 queryjournal 查询。 不要用下列命令测试或重置日志：

fsutil usn deletejournal /d C：

删除日志会影响使用该日志的应用程序，且可能需要完整扫描磁盘区; 重新建立或调整日志大小前，请先确认应用程序厂商的建议。 Microsoft：建立、修改及删除变更日志

若您能提供监控应用程序的名称与版本、受影响磁盘区的日志查询结果，以及应用程序记录中的相关错误码（请遮蔽任何敏感信息），就能进一步判断是日志被重建、旧记录已被修剪，还是应用程序未能正确处理日志识别码变更。 感谢您提供这些信息，我们可以依结果继续缩小问题范围。

注：本答复使用翻译工具翻译，可能包含文法或内容上的错误，敬请见谅。 感谢您的理解。