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.

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.

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

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,