Win32: Work-around for GetFileAttributes()
I'm noticing a problem that has crept up a few times over the years, and seems to be happening a lot under Windows 7 in our current build.
When I test for the existence of a file, using ::GetFileAttributes(filename), I am often getting back INVALID_FILE_ATTRIBUTES, and GetLastError() is ERROR_PATH_NOT_FOUND (3).
However, the file does exist, the path exists, the volume exists - its H:\Foo\Bar - which is a folder on a network share that is mapped on my machine to H:.
If I open a command window, it can see it. If I use Windows Explorer to navigate to that folder, it can see it.
If I do those before running our app, we can see it.
But if I run our app first, after a reboot, before anything has attempted to view H:\, then I get the above error repeatedly.
It has always seemed to me that Windows is "helping" me by returning ERROR_PATH_NOT_FOUND immediately when the given share-mapping hasn't been reconnected this session (it is set to auto-reconnect). This is, needless to say, anno开发者_开发知识库ying. Is there another API call I could be making to "determine if file/folder X exists?"
Are you running the application as a service? Or as some other user? It may be a permissions issue. The credentials it's using may not have permission to read that directory.
The drive connection needs to be restored, that's done automatically by the shell. It used to be done by WNetRestoreConnectionW() but that function has been removed in Vista. I think you'll need to do it this way now.
Using a UNC path (\\share\dir\file
) might be the better cure.
An easier way is to use ShellExecuteEx
with the flag SEE_MASK_CONNECTNETDRV
.
精彩评论