I have written a tool to collect log files within a time window specified by the user of the tool. Up until now I was basing the collection of log files by using the File.GetLastWriteTime method on the log files, comparing this to the times the user entered and collecting based on the outcome of these comparisions. Here is a small code snippet:
DateTime logFileEnd = File.GetLastWriteTime(matchingActiveLogFile);
However I noticed my tool didnt collect some log files I thought it should have done. It seems the DateTime returned by this method was out of date, (there was more recent logging in the file than the value of this datetime).
When I looked at the 'Date Modified' of the file in question, it too was 'out of date', there was more recent logging in the file than the 'Date Modified'.
How I can I get an accurate 'GetLastWriteTime' or Date Modified value?
During my experience I went throw a couple of issues like yours. On Windows Vista/7 systems that function not always returns a reliable result.
After a while we found this link: Disabling Last Access Time in Windows Vista to improve NTFS performance
An observant Windows Vista user noticed a registry named
NtfsDisableLastAccessUpdate
underHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ControlFileSystem
and asked us what this means.Last Access Time is a file attribute that’s updated when a file is accessed or otherwise touched. (This is often confused with the Last Modified Time, which is only updated when the file changes.) Last Access Time has a loose granularity that only guarantees that the time is accurate to within one hour.
In Windows Vista, we’ve disabled updates to Last Access Time to improve NTFS performance. If you are using an application that relies on this value, you can enable it using the following command:
fsutil behavior set disablelastaccess 0
You must restart the computer for this change to take effect. For more information about the Fsutil command and Last Access Time, see the Fsutil online Help.
Based on this it became clear that last access time can not be used as a "strong key". To resolve that issue, we just stop relaying on GetLastWriteTime
call, but store last changed value of the file or in its name, like "FileName_yyyymmdd"
, or inside that file in some field.
There is another solution for GetLastAccessTime
can find here:
.NET FileInfo.LastWriteTime & FileInfo.LastAccessTime are wrong, could be useful in your case too.
My general opinion on this would be: do not relay on that parameter, but invent something else in your architecture.
Good luck
Tigran is right:
You can try to compare file size changes, in addition to last write time. It's what I do (with FileSystemWatcher, but it's similar to compare fields within a time window).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With