lievencardoen
14th June 2006 10:23 UTC

SetShellVarContext all --> $DOCUMENTS

SetShellVarContext all
MessageBox MB_OK $DOCUMENTS

CancerFace
14th June 2006 11:52 UTC

Strange, I am also getting the same ...
CF

Anders
14th June 2006 15:00 UTC

works for me (XP SP2 MCE2k5)

lievencardoen
14th June 2006 15:23 UTC

Well, apparently it is not to be trusted...

JeronimoColon
15th June 2006 23:03 UTC

Any word on this? I'm experiencing the same problem.
All the PCs I'm testing this on are Windows XP SP2.

I created a sample install and all it does is:
SetShellVarContext all
DetailPrint "All DOCUMENTS: $DOCUMENTS"

SetShellVarContext current
DetailPrint "Current DOCUMENTS: $DOCUMENTS"

On some PC it behaves correctly but on others this is what I get:
All DOCUMENTS: C:\Documents and Settings\jcolon\My Documents
Current DOCUMENTS: C:\Documents and Settings\jcolon\My Documents
Completed

I cant seem to figure out what's different between all these PCs. I'll keep checking and post back if I find anything.

jc3

JasonFriday13
15th June 2006 23:49 UTC

I have tried your example code, and it dosen't seem to work. I have tried it with $DESKTOP, $VIDEOS, $MUSIC, and $PICTURES, and these all work. Could be a bug that has not been fixed (or windows has changed the way the 'My Documents' folder is stored :().

Comperio
16th June 2006 00:33 UTC

hmm... mine works fine. I have XP pro SP2.

Out of curiosity, on those machines that have the problem,
what version of Windows XP is being used? (Home, pro, media edition, 64-bit, etc.)

And when you're in windows Explorer, do you have a 'shared documents' folder? If so, I presume that takes you to the 'all users' folder (ie C:\documents and settings\all users\documents)?

[edit]
I found this blog that talks about problems with the 'shared documents' folder:
http://blogs.msdn.com/jmazner/archiv...29/363160.aspx

And this article about how to disable the 'shared documents' folder by editing the registry:
http://www.winguides.com/registry/display.php/1220/

(Just thinking that if maybe the shared documents folder has been disabled, you can reverse to 're-enable' it.)

Anders
16th June 2006 00:51 UTC

That just removes them from "my computer". BTW I'm running as a restricted user and it still works

JasonFriday13
16th June 2006 02:41 UTC

I have XP Pro SP1 x86(haven't tried it yet) at home and the college computers are XP Pro SP2 x86.

lievencardoen
16th June 2006 07:55 UTC

I will look into it as soon as possible, but I still think it is a bug in nsis. Workarounds are an option, but not a solution.

JeronimoColon
16th June 2006 15:23 UTC

What's strange is about half the PCs I've tried exhibit the problem (Mine is one of them), and the other half behave correctly.

Also, as JasonFriday13 stated the $Documents variable seems to be the only one behaving oddly - even on my machine (which has the problem) the other variables behave correctly. As someone else suggested it may be a problem with just $Documents.

And also, Comperio asked about the exact version Windows I was testing with. I work for a software firm and we are all Dell (Intel x86) with Windows XP Pro SP2. I still have to look at the blog info you have provided and do more digging.

Finally, I created both a standard User account and a standard Admin account when testing and it didn't make a differenct so I think we can rule out permissions.

I'll keep looking...

Afrow UK
16th June 2006 17:30 UTC

Works fine for me as well. Windows XP Pro SP2.
Just tried it on NSIS v2.15 and then installed v2.17 and it still works.

-Stu

CancerFace
16th June 2006 18:47 UTC

I am buffled. I am also using XP Pro SP2. Both calls get the value from HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Personal (using NSIS 2.17) ...
CF

Anders
16th June 2006 20:00 UTC

I just tried it with NoSharedDocuments=1 and it does seem to disable the common folder since I get my local one

JeronimoColon
16th June 2006 20:23 UTC

Just an FYI, I have checked, none of the PC have the registry setting set (both work and non-working).

jc3

JeronimoColon
16th June 2006 22:04 UTC

Okay, I had a theory I just tested. The only thing I noticed that was different between the "work" PCs and the "Non-Working" PCs was the "Non-Working" PCs are part of a Windows Domain. All the "Working" PCs were never added.

Now what I don't know and I need to find out is if this is Windows policy related or default behavior. I don't think we use Windows policies (or very little) but I'll find out if and which - if we are using them.

For those of you who have chimed in can you report whether or not you are part of a Domain or not?

I'll keep digging...

Thanks.

jc3

Anders
16th June 2006 22:26 UTC

The two XP SP2 (One is MCE2k5 and one is Pro) computers I tested on are not in a domain

Afrow UK
16th June 2006 22:55 UTC

No domain here, just a workgroup.

-Stu

CancerFace
16th June 2006 23:37 UTC

I am not in a domain either but it is not working :(
CF

Anders
17th June 2006 15:00 UTC

but do you have NoSharedDocuments=1 (in HKCU or HKLM)

CancerFace
17th June 2006 18:36 UTC

Good point Anders!

For me it is the HKLM value of NoSharedDocuments that makes the difference :)

If it is set to 1 then I can only see the user's $DOCUMENTS regardless of the SetShellVarContext value

CF

JeronimoColon
19th June 2006 14:57 UTC

Just to reiterate, we do not have NoSharedDocuments set at all.

Could a Dev. chime in please?

Thanks.

jc3

onad
20th June 2006 10:27 UTC

This might be of help:

http://www.cs.wisc.edu/~rkennedy/my-documents

If this part of NSIS is not working for you, the best would be to enter a defect in the defecttracker(bug)

and then focus on what you want to achieve and not use the $DOCUMENTS var but make you own routine via the system module.

After all it handy to use default values but not obliged, and if it does not work one better finds an alternative for himself thad does.

I'm sad to say but creating installer and programming just IS a lot of work once in a while...

JeronimoColon
20th June 2006 16:06 UTC

Thanks for the info link Onad. I wasn't aware of the defecttracker so I will enter a bug.

jc3

JeronimoColon
20th June 2006 19:19 UTC

Here's my Win32 API workaround for those who may be interested:

Function GetSharedDocPath
# Win32 API documentation:
# Call: http://msdn.microsoft.com/library/de...folderpath.asp
# Enum: http://msdn.microsoft.com/library/de...nums/csidl.asp

SetPluginUnload alwaysoff
StrCpy $1 ""
IntOp $2 0x002e + # CSIDL_COMMON_DOCUMENTS (0x002e)

System::Call 'shell32::SHGetSpecialFolderPath(i $HWNDPARENT, t .r1, i r2, i r3) i .r4'

SetPluginUnload manual
System::Free 0

DetailPrint "API Call Results: $1"
FunctionEnd

[edit]new links

The API reference is:
http://msdn.microsoft.com/en-us/library/bb762204(VS.85).aspx

The Enum is:
http://msdn.microsoft.com/en-us/library/bb762494(VS.85).aspx
[/edit]

JasonFriday13
21st June 2006 00:26 UTC

I have made a wiki page here using JeronimoColon's NSIS example, just so people can use it for future reference.

Anders
21st June 2006 16:27 UTC

Seems to be related to http://sourceforge.net/tracker/index...49&atid=373085

Nsis uses SHGetSpecialFolderLocation since SHGetSpecialFolderPath needs shell v4.7(IE4 desktop update)

Maybe nsis should check and use SHGetSpecialFolderPath if it is available on the system

JasonFriday13
22nd June 2006 22:48 UTC

I have just tried SetShellVarContext all at home on my XP pro SP1 x86 machine, and it works just fine.

kichik
27th June 2007 14:41 UTC

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.

Anders
27th June 2007 15:40 UTC

After some quick testing, it seems like only $DOCUMENTS is affected, $PICTURES and the other folders inside my documents still resolve to the all users path

curr $DOCUMENTS: C:\Documents and Settings\Anders\Documents
all  $DOCUMENTS: C:\Documents and Settings\Anders\Documents
curr $PICTURES: C:\Documents and Settings\Anders\Documents\Pictures
all  $PICTURES: C:\Documents and Settings\All Users\Documents\My Pictures
curr $MUSIC: C:\Documents and Settings\Anders\Documents\Music
all  $MUSIC: C:\Documents and Settings\All Users\Documents\My Music
curr $VIDEOS: C:\Documents and Settings\Anders\Documents\Videos
all  $VIDEOS: C:\Documents and Settings\All Users\Documents\My Videos
curr $DESKTOP: C:\Documents and Settings\Anders\Desktop
all  $DESKTOP: C:\Documents and Settings\All Users\Desktop
curr $APPDATA: C:\Documents and Settings\Anders\Application Data
all  $APPDATA: C:\Documents and Settings\All Users\Application Data
curr $TEMPLATES: C:\Documents and Settings\Anders\Templates
all  $TEMPLATES: C:\Documents and Settings\All Users\Templates
curr $STARTMENU: C:\Documents and Settings\Anders\Start Menu
all  $STARTMENU: C:\Documents and Settings\All Users\Start Menu

nsnb
8th March 2009 16:11 UTC

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.

Anders
8th March 2009 21:18 UTC

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.