>Hi Lauren,
>
>It's funny how at one point you think you understand a problem, then think you're mistaken, only to come back to the original conculsion. That's the case here. In my original post, I thought that you were saying one thing, then, after your reply, thought that the problem was something else. In this case, my initial, and admittedly "gut" reaction was correct.
>
>At first, I thought that you were wondering about why there was a difference between the time you wrote the file to the and the time the API reported. Later, I thought that you were saying that there was a difference between the times that VFP reported (via ADIR() and FTIME()) as opposed to the time the API reported.

Yes, it's the discrepancy between VFP's ADIR and FTIME functions and the API results that I'm concerned about.

>As it turns out, my initial reaction appears to be correct. Here's another quote from the Platform SDK:
>
>"Not all file systems can record creation and last access time and not all file systems record them in the same manner. For example, on NT FAT, create time has a resolution of 10 milliseconds, write time has a resolution of 2 seconds, and access time has a resolution of 1 day (really, the access date). On NTFS, access time has a resolution of 1 hour. For more information, see File Times."
>
>What the above means is that it's perfectly normal for you to call GetFileTime() and have it report a time later than the system clock (as demonstrated in your code) shows.

Agreed, on certain file systems this might be expected. However, I think you may still miss my point. On an NTFS system, the getFileTime function returns high resolution and quite accurate (as far as I can tell) results. Under NTFS, the ADIR() and FTIME() functions, looking at the *same* file will return less accurate results. It seems as if the ADIR and FTIME() functions are set to work for the older file systems and disregard the extra accuracy afforded by the NTFS attributes. In fact, the results produced by ADIR and FTIME are consistent with dropping the 2^0 place in the binary time provided by the API.

This chart tells the story I think. These results were generated by writing to and then checking the file's attributes with VFP,API and WSH in a tight loop 1000 times under NTFS. You can see that the api line is quite smooth, it reports times to the milisecond (not sure how accurate they are, but the info is there for the taking). WSH, takes the FLOOR() of the attribute which is reasonable. ADIR and FTIME however, take a CEILING() over the EVEN numbers, meaning results from ADIR and FTIME will almost always be ahead of the actual file's last-write time, sometimes by as much as 2 seconds. I suspect the code driving ADIR and FTIME was written in the days of FAT and has not been updated to leverage the increased resolution of NTFS drives.

So, I agree that the file time resolution might differ under different file systems, but I don't agree that the native VFP functions return the most accurate information available about a given file.

>However, having had the opportunity to review your code, I have a couple of comments that may be of help.

I agree with most/all of your comments. I can't take credit for the code, I just copied/pasted from this MS KB article: http://support.microsoft.com/support/kb/articles/Q188/9/77.asp it was just a "quickie" fix to get API results.

And your right about the Win9x issue, the file system is the issue, not really the OS.

>1. Your code has the following:

* DEFINEs for access right
>#DEFINE GENERIC_READ  hex2dec("80000000")
>#DEFINE GENERIC_WRITE hex2dec("40000000")

There's really no need for the Hex2Dec function. VFP can interpret hex values very well. In this case

#DEFINE GENERIC_READ  0x80000000
>#DEFINE GENERIC_WRITE 0x40000000

the benefit is twofold. First, you don't have additional code to maintain. Second, when the code is compiled the expression GENERIC_READ, for example, is replaced with hes2dec("80000000") in your case. By substituting #DEFINE GENERIC_READ 0x80000000 the compiler replaces GENERIC_READ with 0x80000000. As a result, when the code is run, in your case, the additional overhead (admittedly small) of calling the hex2dec function is incurred.
>
>In short, by using the constants you have less code to maintain and it's more efficient.
>
>2. Your statement in the comments about the code not running under Win9x isn't correct. I won't run under a FAT drive, but functions very nicely under FAT32. Since most (I assume) hard drives running under Win9x are running under FAT32, this means that the code will work as designed and return the proper results.
>
>3. This is a personal preference. If I were writing this routine, I'd pass the date/time stamp back as a date/time varible. This means that I'd use CTOT() (rather than CTOD()), or (and in my case, preferably) DATETIME() and passing the month, day, year, etc. as parameters to it.
>
>4. And this is really a personal preference for many people that I know and have a great deal of respect for don't follow it. Rather than having individual functions conversions of a WORD to a string or integer, and another for dealing with DWORDS, I'd have one for the conversion to and one from the conversion from that's capable of dealing with any integer regardless of size.
>
>Regards,