Old 14th June 2006, 10:23   #1
lievencardoen
Junior Member
 
Join Date: Apr 2006
Posts: 43
SetShellVarContext all --> $DOCUMENTS

code:
SetShellVarContext all
MessageBox MB_OK $DOCUMENTS



This still shows the path to my local user documents and not to all users documents...

Why? I'm working on Windows XP SP2, so this should work, as all users folder does exist...

Lieven
lievencardoen is offline   Reply With Quote
Old 14th June 2006, 11:52   #2
CancerFace
Senior Member
 
Join Date: Apr 2006
Posts: 289
Send a message via ICQ to CancerFace
Strange, I am also getting the same ...
CF
CancerFace is offline   Reply With Quote
Old 14th June 2006, 15:00   #3
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,171
works for me (XP SP2 MCE2k5)

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 14th June 2006, 15:23   #4
lievencardoen
Junior Member
 
Join Date: Apr 2006
Posts: 43
Well, apparently it is not to be trusted...
lievencardoen is offline   Reply With Quote
Old 15th June 2006, 23:03   #5
JeronimoColon
Junior Member
 
Join Date: Sep 2004
Location: New York City
Posts: 39
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
JeronimoColon is offline   Reply With Quote
Old 15th June 2006, 23:49   #6
JasonFriday13
Major Dude
 
JasonFriday13's Avatar
 
Join Date: May 2005
Location: New Zealand
Posts: 881
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 ).

"Only a MouseHelmet will save you from a MouseTrap" -Jason Ross (Me)
NSIS 3 POSIX Ninja
Wiki Profile
JasonFriday13 is offline   Reply With Quote
Old 16th June 2006, 00:33   #7
Comperio
Major Dude
 
Comperio's Avatar
 
Join Date: Jan 2005
Location: Oregon Coast
Posts: 737
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.)
Comperio is offline   Reply With Quote
Old 16th June 2006, 00:51   #8
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,171
That just removes them from "my computer". BTW I'm running as a restricted user and it still works

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 16th June 2006, 02:41   #9
JasonFriday13
Major Dude
 
JasonFriday13's Avatar
 
Join Date: May 2005
Location: New Zealand
Posts: 881
I have XP Pro SP1 x86(haven't tried it yet) at home and the college computers are XP Pro SP2 x86.

"Only a MouseHelmet will save you from a MouseTrap" -Jason Ross (Me)
NSIS 3 POSIX Ninja
Wiki Profile
JasonFriday13 is offline   Reply With Quote
Old 16th June 2006, 07:55   #10
lievencardoen
Junior Member
 
Join Date: Apr 2006
Posts: 43
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.
lievencardoen is offline   Reply With Quote
Old 16th June 2006, 15:23   #11
JeronimoColon
Junior Member
 
Join Date: Sep 2004
Location: New York City
Posts: 39
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...
JeronimoColon is offline   Reply With Quote
Old 16th June 2006, 17:30   #12
Afrow UK
Moderator
 
Afrow UK's Avatar
 
Join Date: Nov 2002
Location: Surrey, England
Posts: 8,434
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
Afrow UK is offline   Reply With Quote
Old 16th June 2006, 18:47   #13
CancerFace
Senior Member
 
Join Date: Apr 2006
Posts: 289
Send a message via ICQ to CancerFace
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
CancerFace is offline   Reply With Quote
Old 16th June 2006, 20:00   #14
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,171
I just tried it with NoSharedDocuments=1 and it does seem to disable the common folder since I get my local one

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 16th June 2006, 20:23   #15
JeronimoColon
Junior Member
 
Join Date: Sep 2004
Location: New York City
Posts: 39
Just an FYI, I have checked, none of the PC have the registry setting set (both work and non-working).

jc3
JeronimoColon is offline   Reply With Quote
Old 16th June 2006, 22:04   #16
JeronimoColon
Junior Member
 
Join Date: Sep 2004
Location: New York City
Posts: 39
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
JeronimoColon is offline   Reply With Quote
Old 16th June 2006, 22:26   #17
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,171
The two XP SP2 (One is MCE2k5 and one is Pro) computers I tested on are not in a domain

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 16th June 2006, 22:55   #18
Afrow UK
Moderator
 
Afrow UK's Avatar
 
Join Date: Nov 2002
Location: Surrey, England
Posts: 8,434
No domain here, just a workgroup.

-Stu
Afrow UK is offline   Reply With Quote
Old 16th June 2006, 23:37   #19
CancerFace
Senior Member
 
Join Date: Apr 2006
Posts: 289
Send a message via ICQ to CancerFace
I am not in a domain either but it is not working
CF
CancerFace is offline   Reply With Quote
Old 17th June 2006, 15:00   #20
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,171
but do you have NoSharedDocuments=1 (in HKCU or HKLM)

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 17th June 2006, 18:36   #21
CancerFace
Senior Member
 
Join Date: Apr 2006
Posts: 289
Send a message via ICQ to CancerFace
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
CancerFace is offline   Reply With Quote
Old 19th June 2006, 14:57   #22
JeronimoColon
Junior Member
 
Join Date: Sep 2004
Location: New York City
Posts: 39
Just to reiterate, we do not have NoSharedDocuments set at all.

Could a Dev. chime in please?

Thanks.

jc3
JeronimoColon is offline   Reply With Quote
Old 20th June 2006, 10:27   #23
onad
Senior Member
 
onad's Avatar
 
Join Date: Dec 2004
Location: Turkey
Posts: 447
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...

"Just do it"
onad is offline   Reply With Quote
Old 20th June 2006, 16:06   #24
JeronimoColon
Junior Member
 
Join Date: Sep 2004
Location: New York City
Posts: 39
Thanks for the info link Onad. I wasn't aware of the defecttracker so I will enter a bug.

jc3
JeronimoColon is offline   Reply With Quote
Old 20th June 2006, 19:19   #25
JeronimoColon
Junior Member
 
Join Date: Sep 2004
Location: New York City
Posts: 39
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]
JeronimoColon is offline   Reply With Quote
Old 21st June 2006, 00:26   #26
JasonFriday13
Major Dude
 
JasonFriday13's Avatar
 
Join Date: May 2005
Location: New Zealand
Posts: 881
I have made a wiki page here using JeronimoColon's NSIS example, just so people can use it for future reference.

"Only a MouseHelmet will save you from a MouseTrap" -Jason Ross (Me)
NSIS 3 POSIX Ninja
Wiki Profile
JasonFriday13 is offline   Reply With Quote
Old 21st June 2006, 16:27   #27
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,171
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

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 22nd June 2006, 22:48   #28
JasonFriday13
Major Dude
 
JasonFriday13's Avatar
 
Join Date: May 2005
Location: New Zealand
Posts: 881
I have just tried SetShellVarContext all at home on my XP pro SP1 x86 machine, and it works just fine.

"Only a MouseHelmet will save you from a MouseTrap" -Jason Ross (Me)
NSIS 3 POSIX Ninja
Wiki Profile
JasonFriday13 is offline   Reply With Quote
Old 27th June 2007, 14:41   #29
kichik
M.I.A.
[NSIS Dev, Mod]
 
kichik's Avatar
 
Join Date: Oct 2001
Location: Israel
Posts: 11,343
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.

NSIS FAQ | NSIS Home Page | Donate $
"I hear and I forget. I see and I remember. I do and I understand." -- Confucius
kichik is offline   Reply With Quote
Old 27th June 2007, 15:40   #30
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,171
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
code:

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


IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 8th March 2009, 15:11   #31
nsnb
Senior Member
 
Join Date: Jul 2008
Posts: 157
Quote:
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?
nsnb is offline   Reply With Quote
Old 8th March 2009, 20:18   #32
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,171
Quote:
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.
http://nsis.svn.sourceforge.net/view...17&view=markup

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

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Reply
Go Back   Winamp & Shoutcast Forums > Developer Center > NSIS Discussion

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump