Vista: How can setup program get CSIDL_LOCAL_APPDATA

[zlander]

Anyone know what a setup program (QSetup in this case) must do in order to create/access folders under CSIDL_LOCAL_APPDATA when a user launches the setup program from a Standard User account in Vista?

To clarify: When the setup program is run from a Standard User account, a call to SHGetFolderPath(CSIDL_LOCAL_APPDATA) returns the administrator's local appdata folder instead of the Standard User local appdata folder. Does the setup program need to run "asInvoker" in order to access CSIDL_LOCAL_APPDATA?

THX

[RobDog888]

If you are running the setup package as a standard user and trying to have it access the Administrators AppData folder then there will be a permissions issue guarenteed.

Right click your setup package file and click "Run as Administrator". This will run the app with administrator permissions (you will need to enter in the admin credientials when prompted) so it can acccess the admins appdata folder.

Edit: w00t! 49,000 Posts!

[zlander]

If you are running the setup package as a standard user and trying to have it access the Administrators AppData folder then there will be a permissions issue guarenteed.

No, running the setup package from a Standard User account and trying to retrieve the Standard User's Local AppData folder.

Apparently if the setup package is run as administrator (which it must be in order to write files to System32 etc), then a call to SHGetFolderPath(CSIDL_LOCAL_APPDATA) returns the administrator's local appdata folder instead of the Standard User local appdata folder.

[RobDog888]

Ok, then you may need to write the data during the installed programs startup as that way you can obtain the users appdata.
What data are you needing to write in there?

One thought is that if you run an app as admin and you use the GetUserName APi to retrieve the logged on user name, store it in a var and use that to retrieve the users app data path does it return the user's username or the Admin?

[zlander]

Ok, then you may need to write the data during the installed programs startup as that way you can obtain the users appdata. What data are you needing to write in there?

I'm just going to write the files to the common files location (ProgramData). I'd prefer to have everything in the local appdata folder, but this will work well enough.

Thanks for the help.

[RobDog888]

Ok, sorry I couldnt have been of more help.
This definately will be something I will want to look into deeper as Im sure it wont be the last time this specific issue arises.

If you do ever find something please post back so we can know too.

[zlander]

I'll let you know what I find out.

I have discovered that a user running from a Standard User account cannot copy files that are located in the CSIDL_COMMON_APPDATA folder to their CSIDL_LOCAL_APPDATA folder.

The saga continues...

[RobDog888]

The CSIDL_COMMON_APPDATA is the all users appdata folder which takes admin perms to write to.

Seems like something isnt right here. If you need to store stuff in the all users app data folder then running it as admin will work but you also say that you need to write to a users app data folder but not the admins appdata folder. Why is that? Seems you should either write it all to the all users appdata or do a local user install only. Not 1/2 and 1/2.

[zlander]

I finally found a couple of people who have ID'd the same catch 22 and hopefully a solution that I can pass on to my setup program vendor.

Relevant links:

This is the thread that led me to what I think is the correct solution:
http://www.msdner.com/dev-archive/89/24-113-898420.shtm

This is the actual solution:
http://msdn2.microsoft.com/en-us/lib...98(VS.85).aspx

More information on creating a DAL:
http://technet2.microsoft.com/window....mspx?mfr=true

###

[RobDog888]

Hmm, I had found this as just needing to pass the appropriate token and known folder id to gain access to that type of folder as a user with appropriate access to that other users directory..

http://msdn2.microsoft.com/en-us/lib...88(VS.85).aspx



Thanks for the update. I'll check out those links too

[dilettante]

It is possible (for an MSI package anyway) for Windows Installer to run in the user's context. However when operating in this mode Installer has no access to protected registry keys or filesystem locations (Programs). This does allow a user to install and use software even if they have no elevation rights (for example a standard user with no admin user/pw). But you have no choice but to pick another installation target, such as Local AppData.

To create such a "per user" MSI for Vista using Visual Studio Installer 1.1 you have to post-edit the MSI's database or have the user run MSIEXEC manually with a series of command-line switches. You can perform some of the necessary edits using the Orca tool, but not all of them. The remaining task can be done using the MSIInfo tool. I just use a VBScript to do these edits via the Installer automation object model, since they have to be done each time you build a new MSI.

Other MSI generator tools such as those from 3rd parties may have been updated to incorporate the necessary settings without any post-editing. VSI 1.1 is too old to "know about" changes in Windows Installer since it was released.

The three edits required are:

• Change the Custom Action table row that sets TARGETDIR's value to set it to [LocalAppDataFolder]\whatever instead of [ProgramFilesFolder]\whatever.
• Delete any ALLUSER row from the Properties table.
• Set the Summary Info Word Count value's bit 3 to 1 (on). New in Vista and Installer 4.0, this bit means: 0 = Elevated privileges can be required to install this package. 1 = Elevated privileges are not required to install this package.

Of course to just install some data file(s) to Local AppData is in a sense both easier and harder.

If your install runs per machine (elevated) or per user (elevated) you'll have trouble. The latter is the default for MSI packages created with VSI 1.1, I'm not sure what other packagers do by default. The trouble comes about because the Installer is not running in the user's context and thus can't easily locate Local AppData for this "other" user.


If you use a setup technology that is not based on Windows Installer I'm afraid this won't be much help.

In all cases besides per-user non-elevated installs it may be necessary to have some post installation action take place. This might be spawned from the setup run itself (assuming your setup "knows" the right user, run an external process or call a COM library with impersonation) or perhaps as a "first run" action of the application (to copy the per-user data template from a common location into Local AppData, as already suggested above).


I'm not sure where the Installer would obtain the user token and apply it, but it looks like a great idea for an elevated install. Now if somebody can make it work.

[dilettante]

It looks like an MSI with a null ALLUSERS property (which is VSI 1.1's default) should allow this.

By "this" I mean installing elevated into Programs (Program Files) but per-user, and locating data or other files in that user's Local AppData by creating a "custom Special Folder" set to LocalAppDataFolder. With a Vista per-user install only that original user will be able to run the program, only he will see it in Add/Remove Programs, get Start Menu shortcuts, etc.

How this plays out for non-MSI setup packages I can't guess.

[RobDog888]

So doing that will allow it to be run as an admin but write to a local users folder (non-administrator) and the CSIDL_COMMON_APPDATA folder too? Seems that is what hes trying to do.

[zlander]

The key issue here seems to be that any folder created with administrator privileges cannot be used by a program running from a Standard User account. This even includes folders created in the Vista Public folders. It's nutty.

My setup vendor is using SHGetFolderPath() to locate/create folders during the setup process. SHGetFolderPath can be passed a token, ala:

<< htoken: An access token used to represent a particular user. This parameter is usually set to NULL, in which case the function tries to access the current user's instance of the folder. However, you may need to assign a value to hToken for those folders that can have multiple users but are treated as belonging to a single user. The most commonly used folder of this type is Documents. >>

But I don't know if this will work or not. I've suggested he give it a try. I'm waiting to hear back.

I find the lack of clear documentation on this disturbing (having spent the last 12 hours researching it).

I appreciate the input from you folks though!

[randem]

Actually you don't do any of the above... You write to a common folder or the program files folder then at program startup in the users profile you check to see if the files exist, if not then you copy the default files to the users App Data folder.

Occam's Razor

[zlander]

Actually you don't do any of the above... You write to a common folder or the program files folder then at program startup in the users profile you check to see if the files exist, if not then you copy the default files to the users App Data folder.

That is how I would prefer to handle it and how I've always handled it in the past.

Unfortunately... folders created and files written (to *any* folder) under Vista by a setup program running with administrator privileges cannot be accessed (not even copied) by a program running "asInvoker" from a Standard User account.

Unless, (I'm hoping) there is a way around it. ;-)

[randem]

Sure they can i do it all the time. Write your data upon installation into your installation folder, use a separate folder under your installation folder to make it cleaner. That data will be READ ONLY in Vista. Upon running the app in a users profile you check the users app data folder to see if the files exist, if they do not you copy the default files from the folder in the installation folder to the users app data folder... That's it, it works every time and the beauty of this is that if for some reason they want to start over again they can just delete the files and they will automatically be copied to the users app data folder and it will be just like they first started.

Because it's the user who will be copying the data all is well they can access everything they need to.

Don't believe the HYPE!!!

[RobDog888]

But that logic can lead to big headaces with keeping files up to date. If the app gets a new version then you have to ensure that all users will be running off of updated data files and not old copied over ones.

You cant just check if it exists or not. You need to check the versioning too and it has to be non-shared/comon data or al users data will be out of sync / visible to other users too.

The method used for this solution will depend upon your data. Is it common to all users like a database?

[randem]

Easy Now... Don't try to confuse him. He asked a simple question, don't over complicate what he didn't ask for. This is just startup data. If there are updates to the start up data it can be handled the same way NO HEADACHES!!! One just NEEDS to make a solid plan. You can't do thing Willy-Nilly and expect great results...

[RobDog888]

Exactly, which is why things need to be mentioned or the "plans" wont be very solid or reliable.

[randem]

I could point him to a project that already has all of that done and all he would have to do is to add it to his startup procedure... but that is not allowed (by me) here...

[zlander]

I've been informed that I'm missing a switch in the setup package witch allows full access to the files and folders installed.

From the vendor:

=============================================
Allow Full Access to All Users
"The NT-Class operating system has the ability to limit user access to files and directories. Usually an administrator can control the access using the command-line program CACLS.EXE. You can use this option to make sure that all users have FULL Access to all the files and directories that the Setup program has installed. Of course to perform this operation the person who runs the setup program must have administrator right."
=============================================

Setting this option does remedy the problem, though I've asked the vendor to define "FULL Access to all the files and directories that the Setup program has installed" and to identify the method used to grant that access.

More when we come back from a commercial break...

[dilettante]

The only way the "setup program" is going to get Local AppData is to run under that user. Elevating by entering the admin account and password means running under the admin user. To refer to the earlier discussion, I can't see how setup is going to guess at the user you want and obtain its security token to locate that "guessed user's" Local AppData.

This is why people have mentioned installing a base or template file, and having the program copy this base file to Local AppData if it doesn't find a copy present. Yes, subject to version testing and an update process if need be.

Any user can copy from an application folder under Common AppData to one under Local AppData. I just tried it again to be sure. They could as easily copy from the Program Files subfolder for their installed application.

AFAIK, the only reason to start playing with ACLs is if your program insists on allowing standard user access to folders and files stored in an otherwise protected location. An example might be a data folder under the program's installed location. But since we already have Common AppData for this I'm not sure why we'd bother.

[zlander]

Any user can copy from an application folder under Common AppData to one under Local AppData. I just tried it again to be sure. They could as easily copy from the Program Files subfolder for their installed application.

As I said in my last post, I don't know yet what this "Allow Full Access to All Users" option in my installer does/undoes (I'm awaiting details), but when setup is run with the option unchecked, I cannot access any files from folders the installer installed if I run the program asInvoker from a Standard User account.

If I check the option and run the installer, my program runs asInvoker from a Standard User account without any problems.

I have to assume this option is related to ACL permissions, but who knows. I'll keep you posted.

P.S. I also have to assume that this option doesn't exist in most installer packages, which would explain why it was so hard to track down the source of the problem.

[dilettante]

Just to be clear, are you installing the data files involved in this discussion in a subdirectory you create beneath the special folder you've chosen?

Normal practice would be:

[Special Folder]\CompanyName\AppName\file.ext

Where [Special Folder] would be the Common Appdata folder for example.

I suspect that the security on some of the special folders is complex, resulting in subfolders that "inherit permissions" getting access settings different from those of the top special folder. But then again perhaps the installer technology I am using is setting security on these subfolders and files for me. I know I can specify "read only" for any given file I install, in the packaging utility.

[RobDog888]

Seems there is something new being added here by zlander too. Running the installer and accessing files/dirs is one thing but running the installed app as a user and accessing admin dirs is another.

Can you clarify this statement you made?

If I check the option and run the installer, my program runs asInvoker from a Standard User account without any problems.

Are you saying that your installer has an option to run the installation as admin yet install it as a user (under users appdata) and then you can run your app as a user accessing admin files?

[zlander]

Just to be clear, are you installing the data files involved in this discussion in a subdirectory you create beneath the special folder you've chosen?
Normal practice would be:
[Special Folder]\CompanyName\AppName\file.ext
Where [Special Folder] would be the Common Appdata folder for example.

That's what I am doing. At one point I tried having the installer write files to the "All Users" (Public folders) and even those locked me out.

I suspect that the security on some of the special folders is complex, resulting in subfolders that "inherit permissions" getting access settings different from those of the top special folder. But then again perhaps the installer technology I am using is setting security on these subfolders and files for me. I know I can specify "read only" for any given file I install, in the packaging utility.

Yes, I think most installers set the proper permissions by default (mine does, in fact, but I'd turned the option off at some point, thinking it would cause problems with Vista's UAC). What a horrible mistake.

[randem]

You should use the "C:\Documents and Settings\All Users\Application Data" folder for read/write access for all users...

[dilettante]

You should use the "C:\Documents and Settings\All Users\Application Data" folder for read/write access for all users...

That's what it used to be called prior to Vista. On 32-bit Vista (at least) Microsoft installs a filesystem junction to provide that name as an alias to the real location though, so programs will still work.

Vista's Users Replaces XP's Documents and Settings

These folders don't even have to be on C:\ (never did even under XP). The safest mechanism is to use CSIDL_COMMON_APPDATA to locate the folder.

This is normally a hidden folder. You put files there that the program needs but the user is not expected to interact with.

If you want the users to be able to see and manipulate files outside of your program use CSIDL_COMMON_DOCUMENTS instead. In most cases though these would be files where the user tells your program where to put them, via something like a Save as... dialog. In theory your program should be open such dialogs with their current directory set to the CSIDL_PERSONAL location ("My Documents" now just called "Documents"). Lots of users hate this though.

[randem]

Yes, I know all of that... I was just giving an example since I am not allowed to provide the solution...

[dilettante]

Yes, I know all of that... I was just giving an example since I am not allowed to provide the solution...

Well I have to admit that I don't know what that's all about.

Rather than worry about it though, I'll also admit I was being naive about how some installers treat subfolders and files under CSIDL_COMMON_APPDATA.

I've been lucky to only need to put files there to serve as defaults or templates, and let the program copy those to somewhere else like a folder under CSIDL_LOCAL_APPDATA for runtime use including writes. Sadly the default permissions on any CSIDL_COMMON_APPDATA files seems to only allow a standard user to READ those files.

Using an old packager like Visual Studio Installer 1.1 doesn't offer all of the flexibility you need here. I assume that newer and more full-featured ones do. All VSI 1.1 does is give you a bit of control over the read-only file attribute, and not the NTFS Permissions. That's where I got myself confused.


There is still redemption for VSI 1.1 users though. It involves breaking out a tool like Orca once again to modify the MSI database. After much thrashing around I have a script to do this for me now, saving lots of messing around by hand in Orca.

If this is a touchy subject I'll just let it go here rather than explaining it.


I still wonder about this. If you tried to deploy something like an MDB file to a folder under CSIDL_COMMON_APPDATA you'd still be in trouble if you just set the MDB's permissions to allow "Everyone" read/write access. The Jet engine will want to create a lockfile alongside it, and I haven't looked at the full implications of that.

I've heard that a non-admin can create files under CSIDL_COMMON_APPDATA with no problem... but maybe they just get "Owner" rights? A Jet lockfile (.LDB) by nature would normally need multiple users to get at it.

So I guess instead of just setting the MDB to be read/write for Everyone you'd need to have the installer make the folder containing the MDB allow Everyone to create/read/write/delete files in it.


This can all get complicated pretty fast.