NSIS $TEMP Has Different Value












1















I have been noticed $TEMP param has different value when you:




  • run the installer.exe manually (by double clicking)

  • run from Application with Admin rights.


Running manually will result $TEMP = C:/Users/username/AppData/Local/Temp



Running from App with Admin rights = C:/Windows/Temp



CONDITION:



I have an installer that requires system reboot to finish the process.



To achieve that, I make a copy of installer in the $TEMP, and put the path in RunOnce



PROBLEM:



The function works fine (after reboot, the program is updated with new version).



However, at the end of installation process, I am unable to delete the copy of installer because the $TEMP = C:/Users/username/AppData/Local/Temp when running the installer by RunOnce.



In fact, the copy of installer is located in C:/Windows/Temp



QUESTION:



Is it possible to force the $TEMP to always be = C:/Windows/Temp ?



Is there any better solution to workaround the case of installation with system reboot?










share|improve this question























  • What is your RequestExecutionLevel attribute set to?

    – Anders
    Nov 22 '18 at 3:00
















1















I have been noticed $TEMP param has different value when you:




  • run the installer.exe manually (by double clicking)

  • run from Application with Admin rights.


Running manually will result $TEMP = C:/Users/username/AppData/Local/Temp



Running from App with Admin rights = C:/Windows/Temp



CONDITION:



I have an installer that requires system reboot to finish the process.



To achieve that, I make a copy of installer in the $TEMP, and put the path in RunOnce



PROBLEM:



The function works fine (after reboot, the program is updated with new version).



However, at the end of installation process, I am unable to delete the copy of installer because the $TEMP = C:/Users/username/AppData/Local/Temp when running the installer by RunOnce.



In fact, the copy of installer is located in C:/Windows/Temp



QUESTION:



Is it possible to force the $TEMP to always be = C:/Windows/Temp ?



Is there any better solution to workaround the case of installation with system reboot?










share|improve this question























  • What is your RequestExecutionLevel attribute set to?

    – Anders
    Nov 22 '18 at 3:00














1












1








1








I have been noticed $TEMP param has different value when you:




  • run the installer.exe manually (by double clicking)

  • run from Application with Admin rights.


Running manually will result $TEMP = C:/Users/username/AppData/Local/Temp



Running from App with Admin rights = C:/Windows/Temp



CONDITION:



I have an installer that requires system reboot to finish the process.



To achieve that, I make a copy of installer in the $TEMP, and put the path in RunOnce



PROBLEM:



The function works fine (after reboot, the program is updated with new version).



However, at the end of installation process, I am unable to delete the copy of installer because the $TEMP = C:/Users/username/AppData/Local/Temp when running the installer by RunOnce.



In fact, the copy of installer is located in C:/Windows/Temp



QUESTION:



Is it possible to force the $TEMP to always be = C:/Windows/Temp ?



Is there any better solution to workaround the case of installation with system reboot?










share|improve this question














I have been noticed $TEMP param has different value when you:




  • run the installer.exe manually (by double clicking)

  • run from Application with Admin rights.


Running manually will result $TEMP = C:/Users/username/AppData/Local/Temp



Running from App with Admin rights = C:/Windows/Temp



CONDITION:



I have an installer that requires system reboot to finish the process.



To achieve that, I make a copy of installer in the $TEMP, and put the path in RunOnce



PROBLEM:



The function works fine (after reboot, the program is updated with new version).



However, at the end of installation process, I am unable to delete the copy of installer because the $TEMP = C:/Users/username/AppData/Local/Temp when running the installer by RunOnce.



In fact, the copy of installer is located in C:/Windows/Temp



QUESTION:



Is it possible to force the $TEMP to always be = C:/Windows/Temp ?



Is there any better solution to workaround the case of installation with system reboot?







windows installation nsis temp runonce






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 22 '18 at 2:03









undoundo

112




112













  • What is your RequestExecutionLevel attribute set to?

    – Anders
    Nov 22 '18 at 3:00



















  • What is your RequestExecutionLevel attribute set to?

    – Anders
    Nov 22 '18 at 3:00

















What is your RequestExecutionLevel attribute set to?

– Anders
Nov 22 '18 at 3:00





What is your RequestExecutionLevel attribute set to?

– Anders
Nov 22 '18 at 3:00












1 Answer
1






active

oldest

votes


















1














NSIS gets its $Temp variable like this:



First it tries GetTempPath. That function tries (in order): %TMP%, %TEMP%, %USERPROFILE%, and %WINDIR%, and it returns the first variable that exists.



NSIS then tries to write to this directory and if that fails NSIS uses %WINDIR%Temp.



Admin vs non-admin nor UAC elevation is not really the cause of what you are seeing. Sounds more like a configuration or Anti-Virus issue.



You can force $Temp to a specific directory if you really want to in NSIS 3:



Function .onInit
UnsafeStrCpy $Temp "$WindirTemp"
CreateDirectory $Temp
/*
#--# Uncomment to apply the same %TEMP% to child processes #--#
System::Call 'KERNEL32::SetEnvironmentVariable(t"TEMP",t"$Temp")'
System::Call 'KERNEL32::SetEnvironmentVariable(t"TMP",t"$Temp")'
*/
FunctionEnd


I don't actually understand your issue though because the RunOnce entry can tell what it's path is by using $ExePath.






share|improve this answer
























  • Yes, I guess it's not really because of Admin rights. Because the installer is executed by other app (update manager), which is out of my scope. So, I'm not really sure how it becomes C:/Windows/Temp. Anyway, I did a workaround by putting the copy of installer in ProgramFiles, instead of Temp. Thanks for your comments.

    – undo
    Nov 28 '18 at 2:41











  • It probably inherited this temp from the update manager. You can inspect the environment of a process with Process Explorer.

    – Anders
    Nov 28 '18 at 3:07











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53422905%2fnsis-temp-has-different-value%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









1














NSIS gets its $Temp variable like this:



First it tries GetTempPath. That function tries (in order): %TMP%, %TEMP%, %USERPROFILE%, and %WINDIR%, and it returns the first variable that exists.



NSIS then tries to write to this directory and if that fails NSIS uses %WINDIR%Temp.



Admin vs non-admin nor UAC elevation is not really the cause of what you are seeing. Sounds more like a configuration or Anti-Virus issue.



You can force $Temp to a specific directory if you really want to in NSIS 3:



Function .onInit
UnsafeStrCpy $Temp "$WindirTemp"
CreateDirectory $Temp
/*
#--# Uncomment to apply the same %TEMP% to child processes #--#
System::Call 'KERNEL32::SetEnvironmentVariable(t"TEMP",t"$Temp")'
System::Call 'KERNEL32::SetEnvironmentVariable(t"TMP",t"$Temp")'
*/
FunctionEnd


I don't actually understand your issue though because the RunOnce entry can tell what it's path is by using $ExePath.






share|improve this answer
























  • Yes, I guess it's not really because of Admin rights. Because the installer is executed by other app (update manager), which is out of my scope. So, I'm not really sure how it becomes C:/Windows/Temp. Anyway, I did a workaround by putting the copy of installer in ProgramFiles, instead of Temp. Thanks for your comments.

    – undo
    Nov 28 '18 at 2:41











  • It probably inherited this temp from the update manager. You can inspect the environment of a process with Process Explorer.

    – Anders
    Nov 28 '18 at 3:07
















1














NSIS gets its $Temp variable like this:



First it tries GetTempPath. That function tries (in order): %TMP%, %TEMP%, %USERPROFILE%, and %WINDIR%, and it returns the first variable that exists.



NSIS then tries to write to this directory and if that fails NSIS uses %WINDIR%Temp.



Admin vs non-admin nor UAC elevation is not really the cause of what you are seeing. Sounds more like a configuration or Anti-Virus issue.



You can force $Temp to a specific directory if you really want to in NSIS 3:



Function .onInit
UnsafeStrCpy $Temp "$WindirTemp"
CreateDirectory $Temp
/*
#--# Uncomment to apply the same %TEMP% to child processes #--#
System::Call 'KERNEL32::SetEnvironmentVariable(t"TEMP",t"$Temp")'
System::Call 'KERNEL32::SetEnvironmentVariable(t"TMP",t"$Temp")'
*/
FunctionEnd


I don't actually understand your issue though because the RunOnce entry can tell what it's path is by using $ExePath.






share|improve this answer
























  • Yes, I guess it's not really because of Admin rights. Because the installer is executed by other app (update manager), which is out of my scope. So, I'm not really sure how it becomes C:/Windows/Temp. Anyway, I did a workaround by putting the copy of installer in ProgramFiles, instead of Temp. Thanks for your comments.

    – undo
    Nov 28 '18 at 2:41











  • It probably inherited this temp from the update manager. You can inspect the environment of a process with Process Explorer.

    – Anders
    Nov 28 '18 at 3:07














1












1








1







NSIS gets its $Temp variable like this:



First it tries GetTempPath. That function tries (in order): %TMP%, %TEMP%, %USERPROFILE%, and %WINDIR%, and it returns the first variable that exists.



NSIS then tries to write to this directory and if that fails NSIS uses %WINDIR%Temp.



Admin vs non-admin nor UAC elevation is not really the cause of what you are seeing. Sounds more like a configuration or Anti-Virus issue.



You can force $Temp to a specific directory if you really want to in NSIS 3:



Function .onInit
UnsafeStrCpy $Temp "$WindirTemp"
CreateDirectory $Temp
/*
#--# Uncomment to apply the same %TEMP% to child processes #--#
System::Call 'KERNEL32::SetEnvironmentVariable(t"TEMP",t"$Temp")'
System::Call 'KERNEL32::SetEnvironmentVariable(t"TMP",t"$Temp")'
*/
FunctionEnd


I don't actually understand your issue though because the RunOnce entry can tell what it's path is by using $ExePath.






share|improve this answer













NSIS gets its $Temp variable like this:



First it tries GetTempPath. That function tries (in order): %TMP%, %TEMP%, %USERPROFILE%, and %WINDIR%, and it returns the first variable that exists.



NSIS then tries to write to this directory and if that fails NSIS uses %WINDIR%Temp.



Admin vs non-admin nor UAC elevation is not really the cause of what you are seeing. Sounds more like a configuration or Anti-Virus issue.



You can force $Temp to a specific directory if you really want to in NSIS 3:



Function .onInit
UnsafeStrCpy $Temp "$WindirTemp"
CreateDirectory $Temp
/*
#--# Uncomment to apply the same %TEMP% to child processes #--#
System::Call 'KERNEL32::SetEnvironmentVariable(t"TEMP",t"$Temp")'
System::Call 'KERNEL32::SetEnvironmentVariable(t"TMP",t"$Temp")'
*/
FunctionEnd


I don't actually understand your issue though because the RunOnce entry can tell what it's path is by using $ExePath.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 26 '18 at 21:54









AndersAnders

69.7k1075127




69.7k1075127













  • Yes, I guess it's not really because of Admin rights. Because the installer is executed by other app (update manager), which is out of my scope. So, I'm not really sure how it becomes C:/Windows/Temp. Anyway, I did a workaround by putting the copy of installer in ProgramFiles, instead of Temp. Thanks for your comments.

    – undo
    Nov 28 '18 at 2:41











  • It probably inherited this temp from the update manager. You can inspect the environment of a process with Process Explorer.

    – Anders
    Nov 28 '18 at 3:07



















  • Yes, I guess it's not really because of Admin rights. Because the installer is executed by other app (update manager), which is out of my scope. So, I'm not really sure how it becomes C:/Windows/Temp. Anyway, I did a workaround by putting the copy of installer in ProgramFiles, instead of Temp. Thanks for your comments.

    – undo
    Nov 28 '18 at 2:41











  • It probably inherited this temp from the update manager. You can inspect the environment of a process with Process Explorer.

    – Anders
    Nov 28 '18 at 3:07

















Yes, I guess it's not really because of Admin rights. Because the installer is executed by other app (update manager), which is out of my scope. So, I'm not really sure how it becomes C:/Windows/Temp. Anyway, I did a workaround by putting the copy of installer in ProgramFiles, instead of Temp. Thanks for your comments.

– undo
Nov 28 '18 at 2:41





Yes, I guess it's not really because of Admin rights. Because the installer is executed by other app (update manager), which is out of my scope. So, I'm not really sure how it becomes C:/Windows/Temp. Anyway, I did a workaround by putting the copy of installer in ProgramFiles, instead of Temp. Thanks for your comments.

– undo
Nov 28 '18 at 2:41













It probably inherited this temp from the update manager. You can inspect the environment of a process with Process Explorer.

– Anders
Nov 28 '18 at 3:07





It probably inherited this temp from the update manager. You can inspect the environment of a process with Process Explorer.

– Anders
Nov 28 '18 at 3:07


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53422905%2fnsis-temp-has-different-value%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Costa Masnaga

Fotorealismo

Sidney Franklin