views:

191

answers:

2

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, annoying. Is there another API call I could be making to "determine if file/folder X exists?"

+1  A: 

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.

Jay
Running as my developer (admin) login on a Windows 7 x64 Business machine (I am a local admin, no domain involved).
Mordachai
I think you were right. I had to allow VS2008 restart "with additional permissions" several sessions recently as I have been debugging our installer. So this is probably a different user-identity, one that doesn't have H: mapped. Seems like a bug in Win7 (maybe also Vista), since elevating privileges shouldn't cause the app to no longer see the same drives as the user for whom it was elevated...
Mordachai
Mordachai
+1  A: 

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.

Hans Passant
Thanks. I have seen the behavior I originally posted about over the years, and this article sounds like it might allow me to fix that aspect of the problem.
Mordachai