David, >Would the API "GetFileTime" be of any help?
That is worth a try. I know about GetFileTime, but I was trying to use the directory entry data on the theory that it would be more efficient since the file does not need to be opened. I have changed one of the editor programs to use GetFileTime, and tried saving about 20 times without producing the problem. This problem has always come up within 10 saves in the past, so this may be the workaround. If this ends up solving the problem, it was worth going through the exercise just to know that the times contained in the directory entry under Vista are not accurate when read immediately after a save. Thanks for your help, Glenn Lawler www.incodesystems.com -----Original Message----- From: burkleyd [SMTP:burkl...@yahoo.com] Sent: Saturday, April 25, 2009 5:19 PM To: advanced_delphi@yahoogroups.com Subject: [advanced_delphi] Re: Vista directory listing timestamp quirk --- In advanced_delphi@yahoogroups.com, "Glenn Lawler" <gblaw...@...> wrote: > > 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 > Would the API "GetFileTime" be of any help? Declare Function GetFileTime Lib "kernel32" Alias "GetFileTime" (ByVal hFile As Long, lpCreationTime As FILETIME, lpLastAccessTime As FILETIME, lpLastWriteTime As FILETIME) As Long The FILETIME structure looks like... Type FILETIME dwLowDateTime As Long dwHighDateTime As Long End Type David
