Best folder location(s) for application ini

[battler.]

Hi guys,

I'm looking for the best location to save and operate on an application config file (i.e. ini file).

On my Windows 8 machine I've noticed other applications have used many different folders to store app data.

Does anyone know the differences?  Which folders to use, which ones have (read/write) restrictions and why??

C:\ProgramData

C:\Users\Owner\AppData\Local

C:\Users\Owner\AppData\LocalLow

C:\Users\Owner\AppData\Roaming

Does my application need to deal with all or multiple locations (as above) for different users??  What about other operating systems?

[Mark_Yedinak]

We have been using the "Program Data" directory. We need to support applications that are running on XP and Win7. We use the "Get System Directory" VI to get the location of the public application data.folder. This allows us to support both XP and Win7 for a common location for our configuration files. Granted, they are different paths on the two OSs but the approach is common.

[John_P1]

+1 for "Program Data" for application configuration that is not user-specific.

The "Users" folder lets you save different configuration information for each user if you so choose.  Microsoft offers explanation as to what each of the subfolders are used for here.  An excerpt:

Windows uses the Local and LocalLow folders for application data that does not roam with the user. Usually this data is either machine specific or too large to roam. The AppData\Local folder in Windows Vista is the same as the Documents and Settings\username\Local Settings\Application Data folder in Windows XP.

Windows uses the Roaming folder for application specific data, such as custom dictionaries, which are machine independent and should roam with the user profile. The AppData\Roaming folder in Windows Vista is the same as the Documents and Settings\username\Application Data folder in Windows XP.

Best Regards,

[battler.]

Hi Mark,

I have been doing the same till now.  I just noticed programs such as JKI etc using several.

Question: how do you guys handle the case that the user may have manually deleted the config file in the Program Data folder?  I suppose the first step is to check if the file exists before you read it and if it doesn't exist then replace it (create file) with default values stored on the block diagram?  Are there permission issues with creating new files in the Program Data folder?

From my experience sometimes deleting a file from Program Data does not effect the respective program until the computer is restarted..

John,

I still don't understand those definitions..  What do they mean by user "Roaming"?  To where exactly? :-S

[RavensFan]

Battler,

I think what you said about a missing config file is the way I would handle it.  It probably depends on the program, but I would think that once a program reads a config file at the beginning, it no longer cares if someone deletes it.  But I think that would probably persist only while the program is open.  I don't know how that data would persist beyond closing the program until a PC is rebooted.

I believe the PC should allow you to create new files in the Program data folder without needing to be an admin.  At least I'd hope so.  Microsoft has been trying to lock down the hard drive so much, it is getting impossible to do anything productive with your own PC.

I was wondering the same thing about the roaming profile.  How does a user profile "roam" if it is located on a particular PC's hard drive?  The only thing I can figure is that there is possibly some setting that allows the Roaming directory to be located on a network drive that could be accessed from anywhere.  Maybe the "roaming directory" is something that gets defined by a user's network profile at login.

[John_P1]

I haven't yet made use of the Roaming directory myself.  My understanding is that it is for applications which want a user's settings to persist across different computers that are on the same domain.  Based on the wikipedia article, the file appears to be stored on a server and is copied to the local computer's drive when the user logs in (and merged back to the server when the user logs off).  Setting this up is more of an IT-related question than a LabVIEW one.

You don't need Administrator priviledge to create or modify files in the Program Data folder thankfully (otherwise your app would have to run as administrator just to save configuraiton data!).

Best Regards,

[Yamaeda]

The downside of the ProgramData is that is gets the current user rights which can cause problems for other users (it's happened to me), so it's less issues with using the UserData, though each user need to do the settings.

/Y

[GriffinRU]

Keep it simple, keep it close!

With LabVIEW executables you are going to have app.ini file in applications root directory, why creating another one? Use it as configuration file, LabVIEW doesn't mind sharing.

Now, if you would like to follow Windows pattern, than don't use .ini files any more and jump into Windows registry (multiuser, superfast...)

-Artur

[John_P1]

If your app needs to modify the .ini file then putting it in the root direcotry is going to require you to run as administrator assuming you installed the application to somewhere like C:\Program Files, no?

What location in the registry is both shared by all users and is writable by standard users?  The ProgramData direcory is specifically intended for this purpose according to Microsoft's own documentation.

Best Regards,

[GriffinRU]

How do you think LabVIEW application read/write from and to this file upon start and exit, same credentials would be granted to you as the same Labview user.

HKLM\SOFTWARE\YOUR APP -> create during install with admin credentials and use it for configuration parameters

Do not use registry (unless you are admin and know what you are doing) for data sharing. Use Labview variables...

-Artur