billsh
8th June 2007 21:55 UTC

$APPDATA directory creation failure under Vista
I'm trying to create a folder under $APPDATA\FOO for some data files (CreateDirectory "$APPDATA\test"). This fails on Vista, yet I can open a non-admin cmd window and MD that folder with no problems. I can see the correct paths in the Details window so I know I'm in the right place. It will say something like:

Create folder: c:\Users\Bill\AppData\Roaming\test

yet that folder doesn't exist after install.

Is there a way to get win32-type error codes info from this failure? I know it sets the error flag, is there any info stored in registers or variables after that flag is set? I haven't found anything like that in the samples/forum (although I could be just be ignorant and not seeing it). Most just seem to jump to a section that prints an error, but I haven't found any examples that give me something like GetLastError() would.

Cheers!

kichik
9th June 2007 09:28 UTC

There's no way to get the last error. Are you sure it really creates the right directory and you're not just in an elevated account where you actually create something like C:\Users\Admin\AppData\Roamin\test?

GenRabbit
10th June 2007 13:26 UTC

I have had the same problem, It runs smoothly under WinXp and generates a file as expected in the $appdata$ folder. But on Vista its no no. Its not being created.

GenRabbit
10th June 2007 13:33 UTC

Btw here is my installer script. just remove the files to isntall to test it on Vista or something.

pengyou
10th June 2007 17:27 UTC

Creating a folder using $APPDATA\test works OK for me on Vista, using a "standard" account and an installer with RequestExecutionLevel set to "user".

GenRabbit
11th June 2007 00:48 UTC

And how do I set RequestExecutionLevel to "user". I don't have Vista, A friend runs it somewhere far away from me.
Did it work with my installer?

pengyou
11th June 2007 01:28 UTC

And how do I set RequestExecutionLevel to "user"

billsh
12th June 2007 15:43 UTC

I've tried a few things, but still can't seem to create that sucker. I've searched the disk and it doesn't appear that its being virtualized.

Here is a snippet of code:

RequestExecutionLevel user (tried admin too)
...

SetOutPath "$INSTDIR"
File /r "DiskImage\*"

; Move test.inf over to app data folder

ClearErrors
CreateDirectory "$APPDATA\test"
Rename "$INSTDIR\test.inf" "$APPDATA\test\test.inf"
IfErrors 0 +2
DetailPrint "CreateDirectory Failed"


I don't get the failure notice on CreateDirectory, so NSIS thinks it created the folder. The rename call seems to point to the right files (c:\program files\test\test.inf -> c:\users\<me>\AppData\Roaming\test\test.inf). But I can't find that file/directory on the disk anywhere after.

If I try to run Filemon to capture it I get gobs of random NSIS files accesses under c:\users by the setup process, but setup doesn't give me any UI - and the process is still running and can't be killed. So much for being clever!

pengyou
12th June 2007 17:58 UTC

Here is the script for the test program I used on my Vista system.

; Using $APPDATA on Vista

  RequestExecutionLevel   user

  OutFile "demo.exe"
  ShowInstDetails show

Section
        CreateDirectory   "$APPDATA\demo"
SectionEnd

billsh
12th June 2007 22:29 UTC

Thanks! I can run your script and it works great. However if I change user to admin/none it fails. Do you see the same behavior?

I'll need admin to put files in Program Files of course.

Cheers!

pengyou
12th June 2007 23:23 UTC

I changed the "RequestExecutionLevel user" line in my script to "RequestExecutionLevel admin" and recompiled it.

I ran the revised program while logged in as the "Test" user and Vista asked me for the administrator password. After I entered the password the program created the "demo" folder in the administrator's "AppData\Roaming" folder. I deleted the "demo" folder, re-ran the test and the folder got recreated.

I logged in as the administrator and ran the revised program. It created the "demo" folder in the administrator's "AppData\Roaming" folder. I deleted the "demo" folder, re-ran the test and the folder got recreated.

GenRabbit
13th June 2007 12:31 UTC

Can the "RequestExecutionLevel user" be put anywhere in the installer? like just below the !define and !include ?

billsh
13th June 2007 17:33 UTC

I believe I've sorted out the main problem (pilot error). The admin user name is a '.' different that the 'user' name, so first.last vs firstlast. Sorry, missed that period in 1440x900 mode. Beer fine for me. And the folder search won't turn it up cause a user doesn't have perms to the admin data.

So my final behavior is:

Logon Admin:
REL:user- no pw prompt. created in appdata\user
REL:admin - prompt. created in appdata\admin

Logon Std:
REL:user - no prompt. created in appdata\user
REL:admin - prompt. created in appdata\admin

However, it does bring up another interesting question. If you need admin level for copying files to c:\program files, but your app is run in std mode. How will the app find it's data? Its copied to appdata\admin at install time vs appdata\user and the user can't see the admin's tree even if they knew where it was.

I can't seem to find a best practice doc on this, but it must be a common issue as everyone is now supposed to not put data in Program Files.

GenRabbit - you can put it up top with all the initial includes, etc. It yelled at me if I put it in a section.

kichik
13th June 2007 19:16 UTC

The best practice is to create the data files for a specific user from the program itself. The installer should only install global data files.

billsh
18th June 2007 19:47 UTC

Thanks Kichik! What do people do about uninstall? We'll have the same location ambiguity issue, but the app obviously won't know its being uninstalled.

Cheers!

kichik
18th June 2007 20:44 UTC

You just leave the application data behind. If you really want to remove it, you can use EnumUsersReg, but that's rarely done.

99999999
18th June 2007 21:50 UTC

One thing you might do, is to run the application that you want to run in user mode, using the Vista task manager. I have to do this for a similar purpose with my application, otherwise the second time you run the application on Vista, it cannot write to $APPDATA because the directories created the first time, were created with Administrator purposes.

GenRabbit
12th July 2007 12:00 UTC

So what your saying is that if you want to make anything install in C:\programfiles it has to install in Admin modus, billish?

kichik
12th July 2007 17:29 UTC

Of course. That's not even new for Vista.

GenRabbit
14th July 2007 09:48 UTC

Oki, I wasen't aware of that. neither on Vista or WindowsXP. but then again I'm always logged in with admin rights.