Jump to content

Recommended Posts

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

Link to comment

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.

Link to comment

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.

Link to comment

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

Link to comment

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.

Link to comment

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.

Link to comment

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).

Link to comment

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?

Link to comment

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

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.