ADIR() & FDATE() DateTimes not exactly same as OS & FSO

[dbMark]

I was prepared to use the Scripting.FileSystemObject to retrieve the DateLastModified (see code sample in thread184-212462, the code sample there can be used when the user needs DateCreated or DateLastAccessed) when I discovered FDATE({filename},1) which is so very simple to use to obtain the file's last modified DateTime. Neat, very neat!

However, I noticed a small discrepancy between the two groups. For most users it probably doesn't matter, especially if you never mix the two groups' data together for comparisons. But the Windows OS (Windows Explorer, right click on file to see Properties) and the FileSystemObject both report DateLastModified identically while VFP's ADIR() and FDATE({filename},1) both report a DateTime that is always 1 or 2 seconds later.

Is there a reason for this? My guess is VFP (as tested with XP and VFP 9.0 SP1/SP2) could be calculating or rounding the DateTime in a different manner than does the OS and FSO. Anyone know why? It's only a couple 1 or 2 seconds off, but would this warrant a HotFix?

Microsoft supplies VFP code to build the DateTime by calling Kernel32:

http://support.microsoft.com/kb/188977

I reported an error in line 131 of their code sample. The value sent into the GetFileTime() function is CreationTime when it should instead be by reference as [blue]@[/blue]CreationTime

 

[GriffMG]

I have noticed this same problem, when writing a backup routine.

I didn't investigate it further, I just allowed for a couple of seconds either way.

I might now revisit, and use only VFPs date/time.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[Olaf Doschke]

I can't say for sure, but I think VFP's ADIR and FDATE evaluate a DOS filetime, which only has an acurracy of 2 Seconds, while FSO is iving you a more exact filetime.

For usage of Windows API also see news2news. For example here:

http://www.news2news.com/vfp/?example=128&function=94

Bye, Olaf.

 

[dbMark]

I haven't completed my research yet, but here's some more information. It appears to be about volumes, some difference between NTFS and FAT methodologies and/or structure formats.

All four methods to obtain the DateLastModified datetime will match if the file is on a FAT volume or is unchanged after having been copied from a FAT volume.

1. Create a file on NTFS. OS & FSO will report one DateLastModified datetime, FDATE & ADIR will report a datetime 1 or 2 seconds later.

2. Move, cut/paste or copy the NTFS file (copying will change the DateCreated datetime) onto a FAT volume such as a flash drive. OS & FSO will now report the same DateLastModified datetime as FDATE & ADIR had reported.

2. Move, cut/paste or copy the FAT file (copying will change the DateCreated datetime) back onto an NTFS volume. OS & FSO will continue to report the same DateLastModified datetime as FDATE & ADIR report until the next time the file is modified on NTFS whereupon the variance will reappear.

In summary, FDATE() and ADIR() datetimes remain consistent between NTFS and FAT regardless where the file was last modified but OS/FSO will report datetimes 1 r 2 seconds earlier if the last modification was on NTFS.

 

[Olaf Doschke]

dbMark,

that supports what I said. DOS file time format is that stored in FAT, NTFS file time format is more precise, but all files in NTFS also have a DOS file time for backward compatibility. You can also get short DOS names of files on NTFS volumes, see ADIR() nFlags=2: Return short file name (DOS 8.3). And besides that there also is a DOS/FAT file time.

Bye, Olaf.