AppData/LocalLow Temp Directory and Uninstall

Greetings!

I'm using NSIS to install an IE8 browser plug-in into AppData/LocalLow under Vista -- a Protected Mode plug-in. That works as expected and all is well. However, I run into trouble with the automatically generated uninstaller.

I understand that the NSIS uninstaller automatically copies itself into the system's TEMP directory to allow for complete removal of the original directory. Under Vista this points to AppData/Local/Temp, which is fine for a normal application. Unfortunately, this is incorrect for a Protected Mode application, where the TEMP directory should be AppData/LocalLow/Temp. NSIS responds with the following dialog when attempting to launch the uninstaller:

Error writing temporary file. Make sure your temp folder is valid.

It doesn't look like NSIS is taking the Protected Mode into account and switching to the correct directory.

Under the current version of NSIS, is there anything I can do to work around this? Can I force the directory the uninstaller will be copied to? I would even settle for not copying the uninstaller at all and just leave the directory around on the system.

If there is no current work around, are there any plans on supporting these types of Protected Mode applications?

Thanks!

- Dave

If you can pass command-line options to the installer, _?= should solve your problem. See http://nsis.sourceforge.net/Docs/Chapter3.html#3.2

Blame windows for this, NSIS just asks for the temp dir with the official API and we get "the wrong one" (You would expect Protected Mode to handle this, but it does not) If you can point me to a API we could use without hardcoding the path, we should be able to fix it...

As a workaround, generate the uninstaller at compile time like we do with signing, include this uninstaller in a small nsis "application" (not uninstaller) that just extracts the real uninstaller to $appdata\locallow\temp and runs the uninstaller (don't forget to run it with ?= and the path)

Greetings!

I've now come back to this and tried out your suggestions. Thanks coliveira and Anders!

I've gone ahead and did what Anders suggested. I've created a simple installer that wraps around the actual uninstaller. This "uninstaller installer" puts the uninstaller into LocalLow/Temp and does an Exec while including the _?= parameter. Unfortunately, I still end up with the following dialog:

Error writing temporary file. Make sure your temp folder is valid.

Interestingly, this error dialog appears with the "uninstaller installer" even before it gets to copying the true uninstaller. Do NSIS installers also make use of the system's TEMP directory? Or would not being able to access the TEMP directory while creating the %TEMP% constant also cause this error? I suspect Protected Mode is causing even more issues with NSIS.

To test this out, I copied my working NSIS installer -- the one that installs my program I'm trying to uninstall -- into the LocalLow directory. When I try to run it, I get that same error dialog about the temporary file. The installer of course works if it is run from a user's documents directory.

As another test, I manually copied my uninstaller (created using the procedure suggested by Anders) into LocalLow/Temp. I then run it from the command line and include the _?= parameter pointing to the correct directory. And once again, I still get that temporary file dialog.

Finally, I manually copied my uninstaller into the Local/Temp directory and ran it from the command line using the correct _?= parameter. From there it runs just fine.

It would be great if you guys could try this out too. Under a non-privileged account, copy any NSIS installer into a LocalLow directory (could use LocalLow/Temp if you'd like). Then try to run the installer and see what happens. You could also take any NSIS uninstaller executable and run it from the LocalLow/Temp directory with the _?= parameter and see what happens.

At this point, I'm stuck. It doesn't look like NSIS installers or uninstallers may be run from the Protected Mode LocalLow directory (TEMP or not). Hopefully given that this may be tested from any Vista (and Win7?) machine with a non-privileged account, and any NSIS installer or uninstaller, the NSIS code base could be changed in the future to better support Protected Mode. This would include not erroring out when there are issues with the temporary directory (maybe through a command line switch).

Vista sucks in that it doesn't provide the correct APIs to deal with Protected Mode. Nor, from my own experience, does it modify the output of its existing APIs when working in Protected Mode. Unfortunately we need to use Protected Mode to allow for non-privileged plug-ins to run under IE8.

Thanks!

- Dave

I'm guessing we will need to hardcode the temp path to %localappdatalow%\temp if the normal temp path fails

Thanks for replying, Anders.

If someone does go down the path of modifying NSIS to support protected mode, this may help: Getting the Integrity Level for an Access Token

I've not tried it out myself just yet, but it looks like if the process comes back as Low Integrity, assume the localappdatalow Temp directory. Once that change goes in, I'd be willing to test it out. 😁

Thanks!

- Dave

I don't really see the need to check the token, if we don't have write access to %temp% or %windir%\temp, we should just try the low temp dir

update

Originally Posted by Anders View Post

I'm guessing we will need to hardcode the temp path to %localappdatalow%\temp if the normal temp path fails

is $LOCALAPPDATALOW an official variable?
i can't seem to find any documentation on it.
i've been using it for quite a while.. and works well except in XP.. it leaves behind:

Application DataLOW

not that big a deal..

$LOCALAPPDATALOW is not a variable. $LOCALAPPDATA is, so if you enter $LOCALAPPDATALOW it will append 'LOW' to the contents of $LOCALAPPDATA. I'm assuming that the exact name of the locallow folder can be changed by the user, so appending LOW to localappdata will not always work. You'll probably have to call SHGetKnownFolderPath to get the actual path.

LocalLow is not for user business, its strict OS business - keep your fingers off.

Originally Posted by Brummelchen View Post

LocalLow is not for user business, its strict OS business - keep your fingers off.

Apps that run @ Low IL (IE Protected mode) are allowed to use the Low folder, that's what it's there for...