MidnightJava
15th September 2006 07:04 UTC

Can't open file for writing -- Error began when I switched to MUI
I had my installer working fine, and then I switched to MUI. Now I get a mysterious write error for a reason I can't figure out.

I set the installation directory as

InstallDir $PROGRAMFILES\jRAM

Then I execute the following in my main installer Section:

SetOutPath $INSTDIR
SetOverwrite on
File "..\..\JRAM Build\setup\readme.txt"

When the installer comes to this point, it reports "Error openeing file for writing: c\Program Files\jRam"

This is indeed where I want to extract the file to, and the directory exists and I have write privileges for it. The file exists in the source location indicated also, and it can be read.

This worked fine before I put the MUI code in, and I can't see anything I changed that can be causing me to not be able to write files to the installation directory, especially since it's clear that the installer knows the correct path to the installation directory.

I've attached the entire script for context.

MidnightJava
15th September 2006 07:07 UTC

Attachment didn't post for some reason. Here it is.

kichik
15th September 2006 12:17 UTC

The second parameter to MUI_PAGE_STARTMENU should be $StartMenuGroup, not $INSTDIR. The way you have it now, it writes the selected start menu folder name into $INSTDIR, which is, of course, an invalid directory path.

MidnightJava
16th September 2006 06:49 UTC

MUI Start Menu page -- Error creating shortcut (Was: Can't open file for writing)
Thanks, kichik. That was the problem. I see now how I misunderstood the documentation.

However, I'm still having trouble with the switch to MUI. I'm having problems creating shortcut icons, and I seem to have traced it to a faulty value being set for $StartMenuGroup by the MUI Start Menu macro.

I use the following to set the variable for the Start Menu Group selected during the install dialog

insertmacro MUI_PAGE_STARTMENU install_page_1 $StartMenuGroup

This variable should be set to the filepath selected by the user. Using DetailPrint, I find that it is actually set to

c\Documents and Settings\Mark\Start Menu\Programs\jRAM

Note that the ":" is missing after the "C"

The result is then that the installer gives error message "Failed to create shortcut" for each Start Menu shortcut. I also get in my Start Menu Programs folder the following folder with subfolders:

c\Documents and Settings\Mark\Start Menu\Programs\jRAM

This is apparently caused by the

CreateDirectory $StartMenuGroup

command, but why the folder gets created in the Start Menu is beyond me. But apparently the failure to create the shortcuts is caused by the missing ":".

I can certainly write a function to insert the ":", but I'm wondering if I'm missing something. I didn't find a bug report about this, and it seems doubtful I'm the first one to find it.

I attached my script file once again, as I made some changes from the last post, to account for the fact that $StartMenuGroup contains the entire path when using MUI, while with the function I was using previously (still in the script, but not called) it only contained the last segment of the path.

MidnightJava
16th September 2006 09:02 UTC

MUI Start Menu page -- Error creating shortcut (Was: Can't open file for writing)
I was able to make it work by massaging the value returned by the MUI Start Menu macro. See attached file.

I would like some input on whether or not I should enter a bug against the MUI Start Menu macro.

I'm also a bit concerned about something that happened in the process. Not sure why, but one of the times I ran the uninstaller in an earler version of the script, I saw a rather disturbing log entry:

Delete on Reboot: c:\Documents and Settings\Mark\Start Menu\Programs

I'm afraid to reboot my system now, lest I lose all my start menu icons. I looked around in the registry and couldn't see a key that indicates this action will be taken on reboot. But I'm not sure where to look. Can someone please tell me where in the registry I should check to make sure this delete doesn't happen on reboot?

kichik
16th September 2006 09:30 UTC

The problem is with MUI_STARTMENUPAGE_DEFAULTFOLDER. You've set it to the complete path instead of just the folder name. It shouldn't contain $SMPROGRAMS.

To find out which files are to be deleted on reboot, use PendMoves.

MidnightJava
16th September 2006 16:56 UTC

Thanks again kichik. SIlly overisght on my part. Thankls also for the recco on Penmoves. However, I'm a bit stumped there as well. PenMoves doesn't seem to have a capability to remove files from pending backup, it just reports them. I looked in the registry in the place that PendMoves says the pending moves and delets are, and I don't have that key. PendMoves, however, does show several items that are pending delete. I searched for some of these in the registry, and I only find them in

HKEY_USERS\S-1-5-21-1604011929-4138158259-2085843710-1009\Software\Microsoft\Windows\ShellNoRoam\MUICache

I have value names under this key that match the names of files that PendMoves says are to be deleted on reboot.

Should I delete these values? Delete the entire MUICache key to be safe?

kichik
16th September 2006 17:11 UTC

The MUICache is not related. PendMoves simply reads the PendingFileRenameOperations key. So if it gives you output, the key is there.

But you don't have to worry so much about it. The files listed there do need to be deleted. If some bug somewhere caused the start menu folder to get in that list (though I'm not so sure it can even delete non-empty directories), simply backup that folder and reboot.

MidnightJava
16th September 2006 17:26 UTC

Found the key and removed it. I was looking in the subkeys in the left pane and overlooking the keys in the right pane next to the values. Using Find is better than browsing. After deleting the key, PendMoves reports no pending file moves.

Thanks again for all your help.