SetShellVarContext all --> $DOCUMENTS

Originally posted by kichik
Seems like a bug in SHGetSpecialFolderPath that the workaround uses rather than a bug in SHGetSpecialFolderLocation which NSIS uses. If a policy in the domain or on the local computer disables the shared documents folder, it shouldn't be accessed. The fact that it still exists doesn't mean it's used.

As for $DOCUMENTS getting the user's path, that's just how every variable works. If the folder for all users can't be found, the current user's folder is used. This way, there should never be an empty shell variable unless it really doesn't exist.

I know this is an old thread, but that's exactly why I am asking: Is the above still valid?

What has been the verdict by the NSIS gurus?

Is this a documented feature in Windows? or a bug in NSIS?

If the latter, has it been fixed since then?

SHGetFolderPath as provided by shfolder.dll is used to get special folders unless the installer is running on Windows 95/98. For 95/98 shfolder.dll is only used for the Application Data and Documents folder (if the DLL exists). Oherwise, the old SHGetSpecialFolderLocation API is called.

I would assume that means its fixed, but to know for sure you would have to test since I can't remember