We had a similar problem in one of our apps with GetFileAttributesA. The solution was to switch to FindFirstFile, FindClose, giving raise to
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
At 06:30 AM 3/25/2004, John Maddock wrote: the 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
Makes sense. pointed
to by FS:[18h]).
Unless that is a published interface unlikely to change, I'd rather call GetLastError(). An offset also might change in a 64-bit Windows environment, which we are likely to be having to deal with soon.
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.
That sounds right to me. GetFileAttributes() is also used by is_directory(), and GetFileAttributesEx() is used a couple of places. I don't know if those usages also need to be changed. It may be the code is OK but the docs need to mention the case where attributes are unaccessible. John, could you take a look at boost-root/libs/filesystem/src/operations_posix_windows.cpp and make any changes you think are necessary? I'm out-of-action for personal reasons for awhile, so can't do it myself. Thanks, --Beman