>I can confirm your results using the code you posted below. It may be a special case, though. A bit of experimentation seems to suggest the problem only surfaces when (a) SET PATH includes the path where the file really is located and (b) you use FILE() to test if the file exists in the drive root. I can't say for sure without some more testing, though.
>
>>To be able to test my code, you must add two lines first

>>set defa to c:\
>>set path to c:\,c:\temp\dir1
>>STRTOFILE('aaa','c:\temp\dir1\xyz.xyz')
>>?FILE('c:\xyz.xyz') &&.T. which is NOT correct!!!!!! Surprise....
>>?FILE('c:\temp\dir1\xyz.xyz') && .T. which is correct

Ahh! I get it now. This could certainly be an issue under some circumstances.

I used the following two lines to prove the problem:

set path to c:\, c:\windows
? FILE("c:\explorer.exe")  && returns .T. even though explorer.exe is not at c:\

I believe if an explicit path is provided to the file people would expect the file to exist at that specific location and not in any of the paths. In the case of large applications with many files and directories with a complex path statements (like SagePro), it becomes more likely that using the File() command could cause side effects that are not expected.

One common issue I could see is that people often copy tables and files into a 'backup' directory that is nested inside of their application. If this backup folder is in the path the file() function could inadvertantly flag a files existance from the backup that does not exist in the live directory.