How can I get the path of a Windows "special folder" for a specific user?

Inside a service, what is the best way to determine a special folder path (e.g., "My Documents") for a specific user? SHGetFolderPath allows you to pass in a token, so I am assuming there is some way to impersonate the user who's folder you are interested in.

Is there a way to do this based just on a username? If not, what is the minimum amount of information you need for the user account? I would rather not have to require the user's password.

(Here is a related question.)


Solution 1:

Please, do not go into the registry to find this information. That location might change in future versions of Windows. Use SHGetFolderPath instead.

http://msdn.microsoft.com/en-us/library/bb762181(VS.85).aspx

Edit: It looks like LogonUser will provide the token for the other user that you need.

Solution 2:

You might try calling ImpersonateLoggedOnUser() to modify a user token for another user, and then passing that to SHGetFolderPath(). Based on the doc for ImpersonateLoggedOnUser(), it looks like you can call LogonUser() to get a token for a specific user.

Just from reading around, I'd guess that the user in question must be logged on in some form in order for this to work. I recall one page stating that the user's registry hive must be mounted in order for this to work (which makes some sense I suppose).

Solution 3:

I would mount the user's registry hive and look for the path value. Yes, it's a sub-optimal solution, for all the reasons mentioned (poor forwards compatibility, etc.). However, like many other things in Windows, MS didn't provide an API way to do what you want to do, so it's the best option available.

You can get the SID (not GUID) of the user by using LookupAccountName. You can load the user's registry hive using LoadUserProfile, but unfortunately this also requires a user token, which is going to require their password. Fortunately, you can manually load the hive using RegLoadKey into an arbitrary location, read the data, and unload it (I think).

Yes, it's a pain, and yes, it's probably going to break in future versions of Windows. Perhaps by that time MS will have provided an API to do it, back-ported it into older versions of Windows, and distributed it automatically through Windows update... but I wouldn't hold my breath.

P.S. This information intended to augment the information provided in your related question, including disclaimers.