LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Best place for configuration files

 


@Dan Lauber wrote:

@blawson:  I'd advise against overriding the directory write permissions.  The reason is that (for example) a virus scans the /program files/ directory, finds an application folder it can write to, and injects an exploit (maybe a glitch in .ini file handling, maybe even modifying your .exe binary to include a little bootloader) and then WHAMO - your user opens your program and infects themselves with a virus.

 

And then they'll blame you for it 😞

 

-Dan


This.  Program Files should be locked down.  Putting .ini or other configuration type files in a program files directory is just slop IMO.  There is a reason why POSIX (Unix, Linux, Mac OS X) systems have been keeping configuration files in user folders for years and locking down program executable directories from non-authorized writes.  MS jumped on board with Vista.  All major OS makers think its a good idea for a reason... and the reason wasn't just to annoy developers.

 

0 Kudos
Message 21 of 26
(1,865 Views)

In my defense, I was merely offering an alternative. If you needed to rewrite everything to switch to user paths, it's simpler and less prone to introducing new problems or errors.  This is exactly how older versions of windows work, after all.  I have a few programs that have to be run as administrator because of this.

 

 

I've noticed that the Get System Directory VI returns "Local" user directory instead of the standard (though confusingly named) "Roaming" directory for "User Application Data".

 

The difference is that when the user is in a user profile roaming setup (log on to a terminal and a server loads your user profile to the local machine), Local is for files that are only available to this user on this machine, while Roaming files are sent from the server to any machine the user logs in to.  Vista and up have roaming and local folders regardless of whether profile roaming is available.  Best practice is to always use roaming unless the data you're storing is too big to repeatedly ship around the network.  The distinction is fine, and in the vast majority of cases it won't make a difference, but it does seem to matter.

-Barrett
CLD
0 Kudos
Message 22 of 26
(1,841 Views)

What if you don't want your application's settings to be different from user to user?  We want our software to run the same if person A or B logs into the machine.  C:\ ProgramData works just fine for win 7 but we install our software many times on XP machines. 

0 Kudos
Message 23 of 26
(1,825 Views)

 


@mpatient wrote:

What if you don't want your application's settings to be different from user to user?  We want our software to run the same if person A or B logs into the machine.  C:\ ProgramData works just fine for win 7 but we install our software many times on XP machines. 


 

There is C:\Documents and Settings\All Users\Application Data in XP or C:\Users\All Users\Application Data in Vista/7.  I'm not sure what the best "virtual way" to get to this location is, but I'm sure it is defined somewhere.  You wouldn't want to hard-path it there, because there may not even be a C:\ or an Administer may have moved the Users folder to another drive.

 

@blawson - Sorry, man.  Didn't mean to jump on your toes but the question is "Best place for configuration files" and not just "a place for configuration files".  You can put configuration files wherever it suits you if you are in a pinch, but I stand by my original position: Program Files isn't the place for these things because you want your programs to run at user permission level not administrator permission level.  I know I've placed configuration files in Program Files before and the problem didn't really present itself until I upgraded to Vista.  And if you think about it, the most annoying thing to users of Vista/7 are programs that require administrative permissions in order to work properly.... they seem old, outdated, and in-need of an update.

0 Kudos
Message 24 of 26
(1,808 Views)

On LV 2009+, the "Public Application Data" input to Get System Path.vi will give C:\ProgramData (Vista/7) or C:\Documents and Settings\All Users\Application Data (XP)

 

Similarly, on that .NET VI I posted earlier in this thread, "CommonApplicationData" will yield similar results. Take this path, append a folder for your company and another for your app and you'll be a good Windows citizen! (and therefore less likely to run into permissions headaches). e.g. C:\ProgramData\MyCompany\MyApp

Message 25 of 26
(1,806 Views)

I found this on the NI website.  It does a pretty good job of summing things up.

0 Kudos
Message 26 of 26
(1,743 Views)