We have a number of applications which are editors of different kinds where we
have included a feature which warns the user that the file he is editing has
been changed since it was loaded. This feature has worked just fine until
Vista. It works fine about 80% of the time in Vista, but produces a false
indication about 20% of the time.
What we originally did with these programs is use the FileAge function to
return the integer which represents the file timestamp, and save it in an
internal variable. Then, whenever the user saves the file, we get the FileAge
again and verify that it has not changed. This has worked reliably with all
versions of Windows until Vista. With Vista, a difference of 2 seconds or less
occurs about 20% of the time even when I know the file has not been changed.
This 2 second difference reminded me of the 2 second file time resolution
limit in DOS, and since FileAge returns an integer containing both
the date and time, I assumed it may be subject to a similar
resolution limit.
In an attempt to get around this problem in Vista, I changed one of the apps to
use the API to get the file time from the directory listing:
var
FindHandle: THandle;
FindData: TWin32FindData;
LocalFileTime: TFileTime;
FindHandle:=FindFirstFile(PChar(FileName),FindData);
if FindHandle <> INVALID_HANDLE_VALUE then begin
FileTimeToLocalFileTime(FindData.ftLastWriteTime,LocalFileTime);
FindClose(FindHandle);
end;
We then use this API comparison to determine if the file has been changed:
if CompareFileTime(NewEditFileTimeStamp,EditFileTimeStamp) <> 0 then
Using this method, we still have the same problem. This appears to be a quirk
in Vista, so the best I am hoping for is some kind of a workaround. It would
seem there must be some reliable way to check the timestamps on files to
determine if they have changed.
Any ideas would be greatly appreciated.
Glenn Lawler
www.incodesystems.com
