Windows folders

[Ulf]

Hi All!

When I build an application(and installation) I normally configure "application builde" to install the program under "\Program files\". I also place the ini-file in the same folder to make sure that correct settings are loaded when the application start. The problem starts if I want to write to the ini-file from the application, then the application have to run in admin-mode(you are not allowed to change anything in \program files if you not are an admin).

The solution to this problem is to move the ini-file/config file to a different folder outside "program files" or use the registry. If I choose to move the file to a different folder, which one do you think I should use? At first I placed the file under "c:\users\user name\documents\application name" but then I realized that there where several other folders that I could use.

What do you think the following folders are for? Should I use one theese folders instead of "c:\usesr\user name\documents"?

c:\ProgramData\ (hidden)

c:\Users\user name\AppData\Local

Best regards

Ulf

[Antoine Chalons]

Hi,

We use C:\ProgramData (and in most cases we like the fact that it is hidden) because that's what we get when we call the "Get System Dir" with "Public Application Data". That said, in the case of our application we don't want customers to play around with the config files, if you do want them to have access to it, you may want to place those config files in a folder that is not hidden.

[Rolf Kalbermatter]

To expand on Antoine's post besides the hidden or non-hidden location you should consider if settings are user or machine specific. Things like hardware configuration you probably don't want to maintain on a per user base, but other things like applications settings (data formats, paths, etc) your most likely will want to keep separate for each user.

[Ulf]

Hi,

We use C:\ProgramData (and in most cases we like the fact that it is hidden) because that's what we get when we call the "Get System Dir" with "Public Application Data". That said, in the case of our application we don't want customers to play around with the config files, if you do want them to have access to it, you may want to place those config files in a folder that is not hidden.

Thank you! Do you known if the installation program "uninstall" stuff in the ProgramData? I guess it quite easy to test...

//Ulf

[Antoine Chalons]

It does, in fact I thinkit uninstalls everything that is installed directly by the install.

[ShaunR]

There is a VI in the "\vi.lib\utilities\lvdir.llb" called "Get Base Labview Directory.vi".

With it you can get the common/user locations that labview uses (like "C:\Users\<user_name>\Documents\LabVIEW Data"

[Jon Kokott]

In Windows XP:

We use "C:/Documents and Settings/All Users/Application Data/<Application Name>"

Supposedly that is guaranteed to give access to everyone.

I'm on my home computer right now and the Program Data folder folder looks promising, I always like a shorter path. Should probably check the official Microsoft recommended stance on this, I know it changed from XP to Vista/7.

[asbo]

I thought I had read somewhere that I/O to the protected Program Files folder was supposed to failover automatically to a mirror ProgramData directory. Anyone know what I'm talking about?

[Jon Kokott]

OK this is a little more definitive.

C:/Documents and Settings/All Users/Application Data/ = C:\ProgramData or C:Users\username\AppData\Roaming folder. I'm getting conflicting forum guidance on that detail.

There is an NTFS Junction point linking those two folders. Win 7 supports symbolic links, so there must be a performance/usability advantage to using a junction instead (or maybe its just more proprietaryier <-lol.)

at any rate, the username can create restrictions between users, use the "All Users" folder and it will be safer.

[crelf]

I prefer to use the registry. We have reuse VIs that read application ini files in their application folder, then when MS really started locking down Program Files, we made drop-in replacements that work with the application's entry in the registry. Plus, that gives us a much easier way to overwrite or add keys outside fo the application's installer (eg: say an installed instance includes a couple of our products + a custom OI: we can install the standard stuff and keep it encapsulated as products, then overwrite any important custom stuff with the custom OI's installer) - works great iff you install stuff in order (there's something not quite right about LabVIEW's installer when it comes to registry keys).

[JamesMc86]

I would beware of ProgramData. It can cause upgrade issues going to Win7 due to access restrictions, seen this catch a few people out.

(null)

[Antoine Chalons]

Hi James,

Can you tell us a bit more about issues with ProgramData?

This is were my installers place the config files for which it needs read/write access. If there are specific issues, I'd like to know :-o

Reminder

[Rolf Kalbermatter]

I would beware of ProgramData. It can cause upgrade issues going to Win7 due to access restrictions, seen this catch a few people out.

(null)

I want to know that too. I'm using Windows 7 Professional here in 32 Bit and 64 Bit on another machine and ProgramData/<Company Name> seemed to work quite well so far. Or where they trying to access it with hardwired names, instead of requesting the location from the OS? Or is it restricted for Guest accounts or similar?

[Ulf]

Hi James,

Can you tell us a bit more about issues with ProgramData?

This is were my installers place the config files for which it needs read/write access. If there are specific issues, I'd like to know :-o

Reminder

Thank you for the Reminder link. I missed that one

[JamesMc86]

For standard accounts you only have read access to ProgramData, not read/write so if the application is to be run by someone it would have to be elevated to admin before being able to write. Rolfk: I wonder whether you have always had admin priveledges or I believe if you have just one user there is some kicker in Win7 which gives the user that creates the folder R/W permissions (I am not sure about this, someone may be able to elaborate better).

The recommendation from Microsoft is that your installer should set permissions for your folder entry in here if you need it. This is not straightforward from LabVIEW but I believe it can be done with a batch file. Another option is that you can sit a mainfest file with your exe which tells Windows that your application must always run elevated (but I suspect this is not recommended practice!). This appears to have caused confusion and problems for programmers across all languages!

Mads link in the reminder is pretty good and will have to keep it on stock. Here it is again and reading the comments you can see the frustration this can cause! http://blogs.msdn.com/b/cjacks/archive/2008/02/05/where-should-i-write-program-data-instead-of-program-files.aspx?PageIndex=2#comments. Primarily because you will have no such issues with the equivalent in XP.

[Antoine Chalons]

This blog post does give some good info, but it doesn't clearly tell us about if an App (or a user) would need to be ran as admin to have write access on the files.

[JamesMc86]

Very true, the short answer is if you are not doing something about it, yes you will need to run as admin to have write access in this folder.

[hooovahh]

Just a thought (and probably not a good one) but what if you install to program files like always, and have the ini file in program files along side the EXE, but then during the install run function that will set the privileges of the INI to be written by any level user?

The EXE doesn't need to have elevated privlages, the file can just have lower ones. I know there is a Windows command line function to set file permissions but I can't seem to find it at the moment. One downside is the file isn't as hidden as other places, but it also feels like a patch when it sounds like the proper way would be to store the data in ProgramData.

[Rolf Kalbermatter]

For standard accounts you only have read access to ProgramData, not read/write so if the application is to be run by someone it would have to be elevated to admin before being able to write. Rolfk: I wonder whether you have always had admin priveledges or I believe if you have just one user there is some kicker in Win7 which gives the user that creates the folder R/W permissions (I am not sure about this, someone may be able to elaborate better).

The recommendation from Microsoft is that your installer should set permissions for your folder entry in here if you need it. This is not straightforward from LabVIEW but I believe it can be done with a batch file. Another option is that you can sit a mainfest file with your exe which tells Windows that your application must always run elevated (but I suspect this is not recommended practice!). This appears to have caused confusion and problems for programmers across all languages!

Mads link in the reminder is pretty good and will have to keep it on stock. Here it is again and reading the comments you can see the frustration this can cause! http://blogs.msdn.co...ndex=2#comments. Primarily because you will have no such issues with the equivalent in XP.

Ok on my own machine I usually run with an account that is part of the admin group and the other computer is a standalone system with only one local user with local admin rights.

But reading through it, it all makes sense. Since Vista, MS has tightened security according to the principle that a user should only have access to resources that do not influence other users on a system. This includes the entire registry except the user specific hive, the filesystem including all setting directories that are used by all users. So ProgramData logically belongs to that. I just added a small piece of code that checks in the configuration dialog the write rights for the configuration file, and if that is not there of the directory and only enables the Save button if this is true. A dialog informs the user that the application needs to be started as admin in order to be able to make changes to the relevant configuration items.

Just a thought (and probably not a good one) but what if you install to program files like always, and have the ini file in program files along side the EXE, but then during the install run function that will set the privileges of the INI to be written by any level user?

The EXE doesn't need to have elevated privlages, the file can just have lower ones. I know there is a Windows command line function to set file permissions but I can't seem to find it at the moment. One downside is the file isn't as hidden as other places, but it also feels like a patch when it sounds like the proper way would be to store the data in ProgramData.

Since Vista you have to differentiate between elevated rights and a user account that has admin rights. The difference is that in order to be elevated one has to start the process explicitedly as admin with an extra password login dialog, even if the current user is already part of the admin group.

Your solution has one possible drawback. Only changing the rights of the config file alone is likely not enough as the directory needs to have its rights also changed. And that allows access to the directory to add more files to anybody, although it should be not possible to change existing files that don't have write rights for normal users.

[hooovahh]

Your solution has one possible drawback. Only changing the rights of the config file alone is likely not enough as the directory needs to have its rights also changed.

This is not the case at all. I can't seem to find the stupid batch file I created, but it would run an installer (with some silent switches) then run the command line program Icacls (built into Windows 7) to allow the INI file that got installed to be written by anyone in the Users local group. This batch file of course would need to be ran by someone with elevated privileges the first time. But then again only someone with those privileges should be installing updates anyway.

Then the application (stored in the Program Files) could modify the INI file that was in the same folder as the EXE, even when the logged in user only had limited rights. This also only modifies the security of the INI file, the directory it self still cannot be modified by someone in the Users group.

[MikaelH]

Hi Ulf

We use a Company Specific folder instead of Program Files.

E.g. C:\<MyCompany>

This folder is pushed from the IT department and gives everybody read and write access to the content in this folder and its sub-folders.

Then I place my application under a program folder like this: C:\<MyCompany>\<MyAwesomeApplication>

The benefit of placing it here is that when the normal operator run it and it prompts for a Automatic Software update, the Update Software have permission to overwrite contents in this folder.

The ini files and other local config files, we store in a different folder that we call:

C:\<MyCompany>\<MyAwesomeApplication>_Data

That's just how we do it down-under.

Cheers,

Mike

[Ulf]

That's just how we do it down-under.

Cheers,

Mike

You don't like restriction, do you? ;-) . I the short run that will be a "good" solution but in the long run, it will be quite messy if all "software developers" create their own folder from root level.

[Rolf Kalbermatter]

This is not the case at all. I can't seem to find the stupid batch file I created, but it would run an installer (with some silent switches) then run the command line program Icacls (built into Windows 7) to allow the INI file that got installed to be written by anyone in the Users local group. This batch file of course would need to be ran by someone with elevated privileges the first time. But then again only someone with those privileges should be installing updates anyway.

Then the application (stored in the Program Files) could modify the INI file that was in the same folder as the EXE, even when the logged in user only had limited rights. This also only modifies the security of the INI file, the directory it self still cannot be modified by someone in the Users group.

Thanks for the clarification. In that case it seems like a good solution unless the directory rights silently get modified too. I should test that but am currently tied up with quite a bit of other things.

[hooovahh]

The benefit of placing it here is that when the normal operator run it and it prompts for a Automatic Software update, the Update Software have permission to overwrite contents in this folder.

The ini files and other local config files, we store in a different folder that we call:

C:\<MyCompany>\<MyAwesomeApplication>_Data

So that means that an operator can simply navigate to the built application and delete the EXE. Now I realize if an operator does this that it would probably be considered malicious behavior. In my opinion giving a user, who likely doesn't fully understand the system, the ability to break a test system so easily is a very big deal. But then again I don't know the type of environment that the system is in, and this may be a fine setup.

[MikaelH]

So that means that an operator can simply navigate to the built application and delete the EXE. Now I realize if an operator does this that it would probably be considered malicious behavior. In my opinion giving a user, who likely doesn't fully understand the system, the ability to break a test system so easily is a very big deal. But then again I don't know the type of environment that the system is in, and this may be a fine setup.

In our production environment it has never been in issue so far, but you're right anybody can delete the exe file.

But I need this for the Automatic update to work.

Every time the user runs the application it checks with our Production Database if this software has any updates, and if so prompts for update.

It starts another LV-application while the original is closing down and then it gets the new server path from the database and overwrites the local copy.