Old 28th January 2009, 08:43   #1
cromev
Junior Member
 
Join Date: Jan 2009
Posts: 3
Angry EnvVarUpdate corrupts PATH

Hi everybody,


in my installer script, I issue the following command:

${EnvVarUpdate} $1 "PATH" "A" "HKLM" ${PATH_EXTENSION_STRING}

In 1 out of 20 cases, this command corrupts the PATH such that is does not append the PATH_EXTENSION_STRING but replace it. The fatal consequence is that almost no software is able to run on the affected machine.

I don't suss for the life of me what's going on, the fact that it only occurs every now and again points to the suspicion that some race condition or other side effect is behind this phenomenon.

Anyone any clue?


Cheers,
Chris
cromev is offline   Reply With Quote
Old 28th January 2009, 12:45   #2
Animaether
Major Dude
 
Join Date: Jun 2001
Posts: 1,173
it only happens occasionally? quaint.

Only thing I can think of is adding debuggery statements (messageboxes or so) at every step of the ${EnvVarUpdate} macro/Function and see where it fails.. and hopefully figure out why.
Animaether is offline   Reply With Quote
Old 5th February 2009, 18:41   #3
smarmit
Junior Member
 
Join Date: Aug 2008
Posts: 4
Hi. What I've discovered may or may not be the same reason your PATH gets corrupted.

There is a limit to the length of the PATH variable. Normally on server types (e.g. 2003 server) that limit is 2048 characters. On XP without a hot fix or SP2, it's 1023.

My QA department found that if their current PATH env var is approaching that limit, and you attempt to add anything over that limit using EnvVarUpdate, it will corrupt the PATH and remove a lot of what was there. This happens with both "A" for append and with "P" for prepend.

I'm still pondering the right thing to do. Count the characters in the existing path, then determine what to do? Also looking at the EnvVarUpdate code to make the fix there (probably the right thing to do).

If you tried appending or prepending more characters to the PATH via the usual Control Panel method, Windows won't allow you to do it. But given EnvVarUpdate does this via the registry directly, the checks are bypassed.

So, not sure if this is what's happening to you, but beware of this anyway.
smarmit is offline   Reply With Quote
Old 6th February 2009, 05:46   #4
Comperio
Major Dude
 
Comperio's Avatar
 
Join Date: Jan 2005
Location: Oregon Coast
Posts: 737
This is the first time I've heard about the path limitation under XP. But then again, most places I've worked for require the latest service packs of Windows always be installed. If that's a problem, perhaps you should check for the existence of the SP or such before you try setting it over the limit.

Another trick might be to figure out the short folder names (8.3 format) of the folder(s) used in the path and use that in the path variable. (The GetShortPathName API could be used with the system plugin to get that info.)

Also make sure you use the large strings version of NSIS to deal with strings longer than 1024 characters, or you may run into similar problems even on a "patched" version of windows.
Comperio is offline   Reply With Quote
Old 26th February 2009, 13:31   #5
cromev
Junior Member
 
Join Date: Jan 2009
Posts: 3
A few weeks ago I decided to NOT use EnvVarUpdate anymore and to use the setx tool instead.

This has been working fine for a while, but yesterday the same thing occured again: the old content of PATH was replaced by my stuff. Again, it only occurs occasionally.

So we basically have one and the same phenomenon caused by two different tools (!!!)

I then issued the setx command from within a batch script (not using NSIS at all!) and did not experience any trouble.

I then returned to NSIS using either EnvVarUpdate or setx, inserted LOADS of debug MessageBoxes, some of them right at the beginning of the installer, displaying the content of PATH to the installing user (ReadEnvStr $R0 PATH). They all tell me that PATH is empty but it is actually not because when I look up PATH in Windows it still holds the original string.

My (tentative) conclusion from this is that there's a general problem with the handling of environment variables in NSIS. Can anyone confirm this?


Ah and BTW, I also suspected a string length problem but that's not the case.
cromev is offline   Reply With Quote
Old 26th February 2009, 14:11   #6
cromev
Junior Member
 
Join Date: Jan 2009
Posts: 3
Just a basic question -- is NSIS deemed capable of running on 64 bit versions of XP? I'm working on 64 bit machines all the time, might this be the cause for my problems?
cromev is offline   Reply With Quote
Old 14th March 2009, 21:41   #7
kichik
M.I.A.
[NSIS Dev, Mod]
 
kichik's Avatar
 
Join Date: Oct 2001
Location: Israel
Posts: 11,342
NSIS strings are limited to 1024 characters. This has nothing to do with x64. You can use the special long string build that limits you to 8192.

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 25th June 2009, 02:40   #8
eigenguy
Junior Member
 
Join Date: Jun 2009
Posts: 1
So I just had the same thing happen to me as this guy did. I'm running NSIS 2.45. This happened WITH the long strings (8192) build, so that is consistent in that it isn't the problem (besides which, the path is <600 characters right now anyway)

The one thing which is similar is that I'm running on a 64-bit system too (Vista). Several executions of the installer and corresponding uninstaller gave NO problems. Then, all of a sudden, the path was GONE with only the item I was adding there.

Has there been ANY follow-up to this? Did cromev ever find a solution?
eigenguy is offline   Reply With Quote
Old 15th April 2010, 19:57   #9
Deko Servidoni
Junior Member
 
Join Date: Apr 2010
Location: Brazil
Posts: 11
Send a message via MSN to Deko Servidoni
My way:
I verified the size of the PATH before and after update it
If the size after was greater than the size before its ok, continue the process.
Else its is corrupt so i abort the process.
Anyone know if its right or will working?
Thanks

PS: if my english is too bad tell me, i am learning yet
=]
Deko Servidoni is offline   Reply With Quote
Old 15th April 2010, 20:20   #10
MSG
Major Dude
 
Join Date: Oct 2006
Posts: 1,894
That works if the expanded variable is always larger than the variable. That doesn't necessarily have to be so, though. It would probably be better to search for the original string (like whatever is supposed to get appended after the expanded envvar) inside the new one.
MSG is offline   Reply With Quote
Old 15th April 2010, 20:47   #11
Deko Servidoni
Junior Member
 
Join Date: Apr 2010
Location: Brazil
Posts: 11
Send a message via MSN to Deko Servidoni
Ok
i will try search for the original inside the new one
thanks MSG
Deko Servidoni is offline   Reply With Quote
Old 1st March 2013, 09:17   #12
TeeWeTee
Junior Member
 
Join Date: Feb 2013
Posts: 14
Don't want to wake old threads however I found one more reason why EnvVarUpdate could corrupt system variables (like PATH):

I tried to add several entries at once:
code:
${EnvVarUpdate} $0 "PATH" "A" "HKLM" "Entry1;Entry2;Entry3"

-> If you call EnvVarUpdate n-times those three entries will be appended three times.

After I changed it to:
code:
${EnvVarUpdate} $0 "PATH" "A" "HKLM" "Entry1"
${EnvVarUpdate} $0 "PATH" "A" "HKLM" "Entry2"
${EnvVarUpdate} $0 "PATH" "A" "HKLM" "Entry3"


everything worked fine (actually I did it in a loop). When calling the code again EnvVarUpdate prints out:
code:
"Target is already present in PATH. It will be removed and appended to PATH"
TeeWeTee 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