cromev
28th January 2009 08:43 UTC

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

Animaether
28th January 2009 12:45 UTC

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.

smarmit
5th February 2009 18:41 UTC

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.

Comperio
6th February 2009 05:46 UTC

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.

cromev
26th February 2009 13:31 UTC

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
26th February 2009 14:11 UTC

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?

kichik
14th March 2009 22:41 UTC

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.

eigenguy
25th June 2009 02:40 UTC

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?

Deko Servidoni
15th April 2010 19:57 UTC

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
=]

MSG
15th April 2010 20:20 UTC

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.

Deko Servidoni
15th April 2010 20:47 UTC

Ok
i will try search for the original inside the new one
thanks MSG

TeeWeTee
1st March 2013 09:17 UTC

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:

${EnvVarUpdate} $0 "PATH" "A" "HKLM" "Entry1;Entry2;Entry3"

${EnvVarUpdate} $0 "PATH" "A" "HKLM" "Entry1"
${EnvVarUpdate} $0 "PATH" "A" "HKLM" "Entry2"
${EnvVarUpdate} $0 "PATH" "A" "HKLM" "Entry3"

"Target is already present in PATH. It will be removed and appended to PATH"