Archive: Delete Files System32
Delete Files System32
Hello,
I created a driver installer. In order to install cleanly, the driver has to first make sure that there are no previous drivers files in the system files. For example, I have to make sure that the paths below do not contain any driver file.
../System32
../System32/drivers
../SysWOW64
In window XP, I just use the delete instruction and they get erased. However, in windows 7, delete does not erase the files. Any idea why is this happening?
Thanks,
What code are you using?
Stu
The code is below. I have already double check that the path is correct.
The first delete uses $WINDIR\System32 instead of $SYSDIR because I thought that the path could be case sensitive. It did not make a difference.
Thanks.
Function cleanFileSystem
# Erase driver files from the system.
delete "$WINDIR\System32\drivers\windrvr6.sys"
delete "$SYSDIR\drivers\pciservo.sys"
delete "$SYSDIR\drivers\pciservo2.sys"
delete "$SYSDIR\wdapi*.dll"
delete "$SYSDIR\drivers\TechnoPCIController.sys" ; from here on, 64 bit only file
delete "$WINDIR\SysWOW64\wdapi*.dll"
FunctionEnd
Running as admin? Got "RequestExecutionLevel admin"?
Stu
I am administrator and even I added an admin check at the beginning of the code (added code below).
what is that "RequestExecutionLevel admin"? can I change the user privileges from the installer?
Function .onInit
# call userInfo plugin to get user info. The plugin puts the result in the stack
userInfo::getAccountType
pop $0 ; pop the result from the stack into $0
# check if user is admin.
${If} $0 != "Admin"
messageBox MB_OK "To install the drivers, log in as administrator."
Abort
${EndIf}
FunctionEnd
RequestExecutionLevel is in the manual.
Stu
thanks, I will check it out.
Please note that requestexecutionlevel does absolutely nothing on older OS versions, or on Vista/7 with UAC disabled. So even if you requestexecutionlevel admin you'll always need to manually check for admin using the UserInfo plugin, like you did.
MSG, thank you for the observation. By chance, do you know how can I pop a message that clarifies that they need to be administrators before showing the admin password info? I see some users getting confused and thinking that the installer needs a password.
Also, getting back to the original question that I had. I am running as admin, an it is still not erasing the files in the system folder. Do you have any idea why is this happening?
Thanks,
Have you disabled file system redirection (see x64.nsh)? If you haven't then Windows will redirect any reads/writes from system32 to syswow64 because NSIS is 32-bit. That is probably what your issue is.
By chance, do you know how can I pop a message that clarifies that they need to be administrators before showing the admin password info?What's wrong with the code you've already posted? It does just that, does it not?
Either that, or the files are in use?
Originally posted by Afrow UKHe/she wants to pop an admin warning before elevation. This is possible with the UAC plugin: Simply pop a messagebox before !insertmacro UAC_RunElevated . But note that this is definitely the long way around. The password entry field shown by Windows is just that, a part of Windows. It's how it's designed. If people misunderstand, that's not your fault because you're only using Windows the way it's designed to be used. So in that vein, it's also not your problem really.
Have you disabled file system redirection (see x64.nsh)? If you haven't then Windows will redirect any reads/writes from system32 to syswow64 because NSIS is 32-bit. That is probably what your issue is.What's wrong with the code you've already posted? It does just that, does it not?
Afrow UK and MSG, both of you rock.
I was missing the X64.nsh redirection macros; that is the reason that I was not erasing the files in the folders I was looking to. Now, I am able to delete the files in the right folders. However, there is still an inconsistency with the next code:
${DisableX64FSRedirection}
CopyFiles $OUTDIR\pciservo.sys $SYSDIR\drivers\pciservo.sys
${EnableX64FSRedirection}
CopyFiles $OUTDIR\wdapi1030.dll $SYSDIR\wdapi1030.dll
The first call copies pciservo.sys into the ...\System32\drivers folder, and I would expect that the second one copies it into the ...\SysWOW64 folder, but it does not redirect to it. It still copies it into the ...\System32 folder. Is the X64.nsh limited to certain api calls?
------
About the message box before admin password pop, I agree with you guys. I believe it is descriptive and simple. So I will leave the pop with the password and the admin, that should be more than enough.
Hmm I've not had that problem before. However, I tend to use this script header in my NSIS projects that need to deal with dual x86/x64 installs (attached). It disables file system redirection by default (for the current thread by the way) and gives you a new $SYSWOW64 variable:
Usage:
${SystemDirsInit}
x86:
$SYSDIR = system32
$SYSWOW64 = system32
x64:
$SYSDIR = system32
$SYSWOW64 = syswow64
So in other words you can just use $SYSWOW64 when you need to extract 32-bit files and you do not need to toggle file system redirection. (Also the header replaces RunningX64 with a non-System plug-in call method of detection.)
Stu
Thanks Afrow UK, that sound like a good way to go.