We had a similar problem in one of our apps with GetFileAttributesA. The solution was to switch to FindFirstFile, FindClose, giving raise to the suspicion that some implementations of GetFileAttributes are broken.
That would be a truly horrible bug. GetFileAttributes() isn't just some minor, rarely used function. It is critical to the correct operation of a number of Boost.Filesystem functions, and I'd guess many tens of thousands of other applications. It is hard to imagine a Windows system staying stable if GetFileAttributes() failed very often.
There is some information in MSDN on this: First off I found an "Under the Hood" article from the September 2000 issue of MSDN Magazine, where GetFileAttributes was periodically failing due to an access permissions problem. The secret was to determine the value of GetLastError after the call (apparently you can get this without actually calling GetLastError by examining the DWORD at offset 0x34 in the thread environment block pointed to by FS:[18h]). So if GetFileAttributes can fail for reasons other than the file not existing, then the return value of GetLastError should also be checked to verify that the reason for the failure really was that the file does not exist: Looks like error codes of ERROR_FILE_NOT_FOUND or ERROR_PATH_NOT_FOUND would be returned in this case. John.