Just for the record, I checked the source for FileAge in SysUtils.pas and found it was doing the same thing I had been doing, that is, using FindFirstFile to get the LastModified time for the file. This explains why my original implementation using FileAge produced the same problem in Vista. So, it would seem that Vista breaks FileAge, unless newer versions of Delphi define FileAge in some other way to avoid this problem.
By the way, I have used the one Editor quite a bit since yesterday and have not encountered the problem one time. So, I would conclude the reliable way to get file times in Vista is with GetFileTime. I have updated our other editors to use this method. Glenn Lawler www.incodesystems.com --- In advanced_delphi@yahoogroups.com, "Glenn B. Lawler" <gblaw...@...> wrote: > > 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...@...] > 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" <gblawler@> > 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 >
