Jeremy, > 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.
That is correct. > 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. I am guessing that some service in Vista is changing the LastModified timestamp. The latency is very small, sometimes just milliseconds, but can be as much as 2 seconds. Our software gets and saves the LastModified timestamp immediately after it saves the file, but between that time and the next time the user saves the file, the timestamp has changed. One possibility that occurred to me was the indexed search service. But this happens even on network shares that are not indexed. The other thing I thought of was a cache latency, where Vista, under certain circumstances only, delays completing the final write of the file. If that is the issue I would still call it a bug since it would make sense that it would write the same timestamp that was originally written to the cache instead of using the current time when the cache is flushed to disk. The other idea I had was that the resolution of the NTFS timestamp might be higher in Vista than the network shares (also NTFS, but some as old as NT4) and Vista rounds the time, but does not do so until the cache is flushed. No matter which of these is the case, I would still consider it a bug; clearly the timestamp should not change. > Meanwhile, a semaphore might work provided your software is always the > editor. The problem is that our software may not be the only editor of the files. > -----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
