RmDir dirs still left

klopfdreh
13th February 2008 15:06 UTC

RmDir dirs still left
Hello,

I'm using a MUI macro to define a function which is executed when the user press cancel:


define MUI_CUSTOMFUNCTION_ABORT abortFunction 

>

In that function I want to delete the installation Folder because I copy some files in a previous custom dialog:


abortFunction

    MessageBox MB_OK "Called"

   RmDir /r /REBOOTOK $INSTDIR

FunctionEnd 

>

After the installer has been closed the files are all deleted, but the directories still exists. The OutPath isn't set "SetOutPath)

Thanks!

kichik
14th February 2008 11:05 UTC

That's a very dangerous function. You don't even check to make sure $INSTDIR was set and that you're in the right page. What if the user is on the directory page, starts to type "C:\Program Files\Application" but only gets to "C:\Program Files" and cancels? You'll wipe out his entire Program Files directory.

As for the problem itself, the directory is probably being used in some way. A possible cause is SetOutPath as you've mentioned. If you're sure it's not it, there are plenty others. You can use Process Explorer to search for open handles to the installation directory.

klopfdreh
14th February 2008 13:54 UTC

Ah, thats right! Good that you post it in here! So what do you think is the safest way to delete it once its set and only those files which are installed?

Thanks!

Edit:

I think the directory is set because I call the custom page after the MUI_PAGE_DIRECTORY


insertmacro MUI_PAGE_WELCOME

>!insertmacro MUI_PAGE_DIRECTORY

Page custom DriverPage DriverPageLeave

>!insertmacro MUI_PAGE_STARTMENU Application $StartMenuGroup

>!insertmacro MUI_PAGE_INSTFILES

>!insertmacro MUI_PAGE_FINISH

>!insertmacro MUI_UNPAGE_CONFIRM

>!insertmacro MUI_UNPAGE_INSTFILES 

>

The only thing I have to do is to check if it is set, don't I?

I found out with:


MessageBox MB_OK $INSTDIR 

>

On each page where I can abort, the path is c:\Program Files\${PRODUCT_NAME}

kichik
14th February 2008 14:19 UTC

You should simply not create the files at such an early stage of the installation. Create the files in the first section. This way, you don't have to delete them in case the user cancels before installation begins.

klopfdreh
14th February 2008 14:31 UTC

I'm get the information, which files have to be copied of a listbox and that is created on a page before the main section. Is there any way to store those references and copy them in a section:


DriverPageLeave

   !insertmacro MakeDirBase "$INSTDIR\driver"

    

    # Copy all drivers into the installation-directory

   Sendmessage $ListBox ${LB_GETCOUNT} 0 0 $0   

    StrCpy$1 0

    loop:

   System::Call user32::SendMessage(i$ListBox,i${LB_GETTEXT},i$1,t.r3)

   CopyFiles $3 $INSTDIRdriver

    IntOp$1 $1 + 1

   ${ifthen} $1 < $0 ${|} goto loop ${|}

>FunctionEND 

>

Afrow UK
14th February 2008 15:03 UTC

http://nsis.sourceforge.net/Validati...fore_uninstall

Stu

kichik
14th February 2008 16:23 UTC

You can save their paths in variables or if you want to save actual files, you can put them in $PLUGINSDIR which is automatically deleted when the installation ends. Just don't forget to call InitPluginsDir to initialize it.

Brummelchen
15th February 2008 13:42 UTC

After the installer has been closed the files are all deleted, but the directories still exists. The OutPath isn't set "SetOutPath"

Ever thought, that INSTDIR ist locked that way from explorer?
Use SetOutPath $EXEDIR to unlock

kichik
15th February 2008 13:47 UTC

SetOutPath doesn't affect Explorer, it affects the installer's working directory.

Brummelchen
15th February 2008 14:02 UTC

>> SetOutPath doesn't affect Explorer

sure - it does - check it with unlocker - explorer locks it as
soon setoutpath is set. you can do all except deleting the directory.

eg setups with a predefined installer (nsis is also a good container)...
nsis extracts - installer needs to point to his directory with
setoutpath - after that i need to point away to delete the temporary directory (dont has to be pluginsdir).
every portable program has that limit.

kichik
15th February 2008 14:07 UTC

Then that's an error on Unlocker's side or Explorer does some dirty trick. In any case, once the installer exits, no one will use the directory anymore. It's not a limitation of every program, it's a conscious call NSIS makes to set the working directory to that specified by SetOutPath.

Brummelchen
15th February 2008 18:44 UTC

>> Explorer does some dirty trick

maybe that - in any case i failed it was explorer who was sitting on it like a mother duck on its egg.
Unlocker didnt failed once here - sometimes i forget to close editor or sandbox which lock folders too - annoying although the document is closed long ago - the working path is still set and that is same problem like explorer behaves.

so i started to set the path afterwards any action to prevent that nevertheless nsis or explorer caused it.