Why does SHGetSpecialFolderPath take such a long time before returning a network error?
A customer reported that their program was failing to start up because the call to
SHGetSpecialFolderPath(CSIDL_PERSONAL) was taking a long time and then eventually returning with
ERROR_BAD_NETPATH. The account that was experiencing this problem had a redirected network profile, “but even if he’s redirecting, why would we get the bad net path error? Does calling
SHGetFolderPath actually touch the folder/network? If so, we should probably stop calling this function on the UI thread since network problems could cause our program to hang.”
SHGetFolderPath function will access the network if you pass the
CSIDL_FLAG_CREATE flag, which says “Check if the folder is there, and if not, create it.”
The customer had been passing the flag. “We’ll remove it. As if our program is going to dictate the creation of the user profile directory.”
CSIDL_FLAG_CREATE flag has been implicated in some other unwanted behavior. For example, if you pass the
CSIDL_FLAG_CREATE flag when asking for
CSIDL_MYPICTURES, this will create a My Pictures directory if there wasn’t one before. Generally speaking, you shouldn’t be creating these directories as side-effects of other actions. Corporate administrators may suppress creation of folders like Pictures and Videos, but that doesn’t do much good if your program casually creates them as part of its startup.
CSIDL values have been superseded by
KNOWNFOLDERID. The flag corresponding to
KF_FLAG_CREATE. If you want to make things even faster, consider passing the
KF_FLAG_DONT_VERIFY flag (formerly known as