jweinraub
26th June 2008 20:13 UTC

AddToPath doesn't always update
I have customers who complain of certain errors during the post installation experience. The reason is the $INSTDIR did not get added to the path at the time of installation.

I can have them manually add it by the control panel but the installation won't. Usually they will need to reboot, reinstall, then the process works.

Any ideas to why, because I can't think of any that make sense. This happens to 1-4% of our users and all of them are solved the same way, but I can not think of a cause to WHY the path didn't add itself during the installation process.

vc6
1st July 2008 23:03 UTC

I see that no one replied, which IMHO means that this is not realy an NSIS problem but an end-user system configuration issue.

I vaguely remember a similar problem in the past, a problem that drove me crazy because nothing in the NSIS documentation could explain what I was seeing. At the end, I discovered that it was simply a matter of correctly identifying the home (install) DRIVE.

The typical Windows system has C: as the home drive. But that's typical, not guaranteed. In your script make sure that you are not hardcoding C: but rather using $%HOMEDRIVE%.

jimpark
2nd July 2008 14:05 UTC

We've had similar issues with AddToPath and discovered two different problems:

1. The PATH variable can be very long which may exceed the 1024 characters allotted by NSIS for a string. There is a BIG string version of NSIS which can handle up to 8192 characters which is enough to handle the PATH variable.

2. The second problem is that the AddToPath function uses two different methods to get the PATH value. The first method is via ReadEnvStr which reads the PATH variable from the current copy of the environment held by the running process. This may not accurately reflect what's in the registry. So the function may fail believing that the path already exists when in reality it only exists in the current copy of the environment held onto by the process. It could be that the uninstall that was run moments before had actually removed the path from the registry but was not able to update the path variable of an existing process like a cmd.exe window. The second read of the environment variable in the IsNT branch of the function uses the ReadRegStr to get the PATH, which only works on NT machines. Our solution was to use the ReadRegStr always and remove the call to ReadEnvStr because we knew our users had machines that ran Windows 2000 and higher.

I hope this helps.

jweinraub
26th March 2009 14:49 UTC

I will have to look into #2 since my path is about 400 chars, but again it works on my PC, but sometimes it doesn't and not 100% sure why. When that happens I have to reboot, reinstall, then it works.