我编写了一个工具，用于按照用户指定的时间窗口收集日志文件。迄今为止，我一直在使用 File.GetLastWriteTime 方法来基于日志文件的最近写入时间进行日志文件的收集，将其与用户输入的时间进行比较，并根据这些比较结果进行收集。以下是一个小的代码片段：
DateTime logFileEnd = File.GetLastWriteTime(matchingActiveLogFile);
然而，我注意到我的工具没有收集一些我认为应该收集的日志文件。似乎此方法返回的 DateTime 已经过期（文件中有比此日期时间值更近的日志记录）。
当我查看相关文件的“修改日期”时，它也是“过期的”，因为文件中有���“修改日期”更近的日志记录。
我如何获取准确的 “GetLastWriteTime” 或者 “修改日期” 值呢？
在我的经验中，我遇到了与你类似的问题。在Windows Vista / 7系统上，该函数并非总是返回可靠结果。
过了一段时间，我们找到了这个链接：禁用Windows Vista中的最后访问时间以提高NTFS性能
一个细心的Windows Vista用户注意到了一个名为
NtfsDisableLastAccessUpdate的注册表项，在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ControlFileSystem下，然后问我们这是什么意思。最后访问时间是文件属性，当文件被访问或者被其他方式触碰时更新。（通常将其与最后修改时间混淆，后者仅在文件更改时更新）。最后访问时间具有宽松的粒度，只保证时间准确到一小时内。
在Windows Vista中，我们已禁用了对最后访问时间的更新，以提高NTFS性能。如果您使用的应用程序依赖于此值，则可以使用以下命令启用它：
fsutil行为设置disablelastaccess 0必须重新启动计算机才能使更改生效。有关Fsutil命令和最后访问时间的更多信息，请参见Fsutil在线帮助文档。
基于此，变得清晰的是最后访问时间不能作为“强密钥”使用。要解决这个问题，我们只需停止依赖GetLastWriteTime调用，而是存储文件的最后更改值或在其名称中存储，如"FileName_yyyymmdd"，或在文件内部的某个字段中。
这里有另一种解决方案可以在GetLastAccessTime找到:
.NET FileInfo.LastWriteTime & FileInfo.LastAccessTime are wrong，在你的情况下也可能很有用。
我的一般看法是：不要依赖该参数，而是在你的架构中发明其他东西。祝你好运。
LastAccessTime与LastWriteTime无关。无论LastAccessTime被记录有什么问题，LastWriteTime都没有这些问题。 - undefinedTigran是正确的:
你可以尝试比较文件大小变化，除了最后的写入时间。这就是我所做的（使用FileSystemWatcher，但它类似于在时间窗口内比较字段）。