Glenn, just to be sure I understand: I think you're finding that the actual timestamp as reported by Vista has apparently been updated, as if the file had been saved, even though you are certain the file has not been saved.
If that's it, then one wonders, is an update being triggered unexpectedly, just
in Vista? Probably nothing you can do about that except get the Vista
developers to correct this apparent bug.
Meanwhile, a semaphore might work provided your software is always the editor.
Jeremy
-----Original Message-----
From: advanced_delphi@yahoogroups.com on behalf of Glenn Lawler
Sent: Sat 4/25/2009 1:45 PM
To: advanced_delphi@yahoogroups.com
Subject: [advanced_delphi] Vista directory listing timestamp quirk
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
<<winmail.dat>>
