Author Topic: User settings storage debate (Read 18036 times)

Josh · « **on:** August 01, 2007, 09:39 AM »

I was having an interesting conversation with a bunch of you in the donationcoder IRC Channel today and I wanted to post this here for more open debate.

What is the best way to store user settings? With the advent of Windows vista, microsoft is pushing users and developers to move from the age old idea of storing settings in the program's program files folder, to storing them under the individual users profile. With portable applications becoming popular, is this the best idea?

I think it is. The sheer idea that a program should require access to write to its program folder after install, to me, doesnt make sense. Once installed, unless running as an administrator, each application should store is own settings in the users data folder thus to allow for customization on a per user basis, and to help prevent infection should one user install something that turns out to be malware.

On the other hand, portability has become hugely popular. For most applications the need for portability really doesnt exist. I mean, most computers we use have certain applications that only make sense to run from your local PC. However, certain applications are nice to have and use on the go (browsers, word processors, web editors, etc). But, this also leads to a security risk as any user can take and plugin their thumb drive and load any application thus bypassying the security setup by any systems administrator.

One idea I think should be done is that each application should give the user the option of making the application portable via an ini file which stores the settings for the application so it can be read from disk vice the registry. I've seen several apps allow users to select, on install or through the options dialog, what mode the application is to be installed (portable or fixed). This is one idea.

What are your thoughts security-wise, portability-wise, etc

Perry Mowbray · « **Reply #1 on:** August 01, 2007, 09:49 AM »

On the other hand, portability has become hugely popular. For most applications the need for portability really doesnt exist. I mean, most computers we use have certain applications that only make sense to run from your local PC. However, certain applications are nice to have and use on the go (browsers, word processors, web editors, etc). But, this also leads to a security risk as any user can take and plugin their thumb drive and load any application thus bypassying the security setup by any systems administrator.
-Josh (August 01, 2007, 09:39 AM)

Thank goodness!! Otherwise, I'd be sunk at work (where IT have tied our computers up so tightly it's hard to scratch whilst working)

One idea I think should be done is that each application should give the user the option of making the application portable via an ini file which stores the settings for the application so it can be read from disk vice the registry. I've seen several apps allow users to select, on install or through the options dialog, what mode the application is to be installed (portable or fixed). This is one idea.

What are your thoughts security-wise, portability-wise, etc
-Josh (August 01, 2007, 09:39 AM)

Having the option is great. I know that ToDoList does it this way, which means USB Drive installations are simple (just extract).

If I was choosing between two similar programmes, being able to install onto a USB Drive would swing me one way or the other (even if I didn't want to install in initially onto a USB Drive), as if I wanted to use it at work it would have to be from the USB Drive.

Armando · « **Reply #2 on:** August 01, 2007, 12:48 PM »

One idea I think should be done is that each application should give the user the option of making the application portable
-Josh (August 01, 2007, 09:39 AM)

IMHO, it would be good to be able (as an option...) to store settings BOTH in the program's program files folder and under the individual users profile -- that way, you're covered.

Every software should also have an option to point to (or import) the right configuration folder/file (so that one doesn't have to guess, paste stuff here and there, and pray that everything will work well afterwards).

Ehtyar · « **Reply #3 on:** August 01, 2007, 04:52 PM »

It's all well and good to say applications should make use of both the registry and files, but i fail to see the benefits of using the registry over files (the speed difference is negligible, after all the only reason registry is faster is because the hive files are in memory). The registry has no benefit for the user IMHO, and is only necessary when integration with windows needs to be achieved. Whereas ini is very helpful for those who use portable storage, which as Josh had just mentioned is becoming more and more popular. Also, you might consider the extra work on the part of the programmer, coding for both registry and ini for no apparent reason. Perhaps it would be good if you posted the debate in text format somewhere so that we may see your reasoning behind your preference of the registry.

Ehtyar.

Josh · « **Reply #4 on:** August 01, 2007, 04:58 PM »

My main question is this. Why should a program have to write to its program files folder after install UNLESS its in portable mode? On a local install, the only folder that should be written is the user's appdata folder. That way, as I said before, drastic changes to a program are limited to said user.

Ehtyar · « **Reply #5 on:** August 01, 2007, 05:11 PM »

I must check myself. Josh and i have discussed this on IRC, and i am now aware of what it is he is pushing, it is most likely my misinterpretation of his words that got me all riled up. Josh believes that app config should be stored in the appdata/profile folder of the specific users, and i must say i cannot disagree with him. I would, however, be opposed to that being the only option available. If an application were to check the current users profile directory prior to check its own directory, i would consider that to be the ideal way of managing user configuration.

Ehtyar.

Josh · « **Reply #6 on:** August 01, 2007, 05:23 PM »

It is, however, individual settings belong in the user's data folder, not in the program files folder. Unix has had this setup for years and its proven to be very secure and easy to setup.

f0dder · « **Reply #7 on:** August 01, 2007, 06:59 PM »

Flexibility, please.

It's not a hard task coding up a configuration class that supports using both the registry (HKEY_CURRENT_USER, of course, since HKLM requires administrative privileges) as well as external config files (whether that be XML or LUA, please no .INI).

As for other configuration files (and where to store an XML or LUA config file), support both %APPDATA% and "alongside the program", to make everybody happy and support both Vista (as well as non-administrative NT4/2000/XP) and portable uses.

It's also not hard coding the program logic that decides whether to use %appdata% or alongside-the-program:

#1 - "userconfig.xml" present in app dir? -> use "portable mode".
#2 - "userconfig.xml" present in %appdata%? -> use "per-user settings" mode
#3 - config not found, ask which mode to operate in.

A HKCU registry check could be added either before, after or instead of step #2.

Ehtyar: one advantage with the registry is that entries are sorted, so lookups can be done with a binary search. Also, there's less text parsing to be done since it's a binary format. It's centralized, and very easy to backup HKEY_CURRENT_USER.

Ehtyar · « **Reply #8 on:** August 01, 2007, 07:57 PM »

Again speed is mentioned. The difference (unless the file is huge, in which case perhaps using the registry would be a better option) will not be noticeable to the end user, and i can't imagine any case where backing up an ini (or xml/lua) in a directory could be harder than backing up a registry hive (would be quicker too if you insist on bringing speed into it).

Ehtyar.

[edit]
You'd also have to admit using the Reg* api is much more code than the *PrivateProfile* api.
[/edit]

Armando · « **Reply #9 on:** August 01, 2007, 11:04 PM »

Yes, flexibility.

As a humble "end user" -- sorry if what I say might seem dumb or naive-- what I like and want is an easy to 1-find, 2-isolate, 3-backup and 4-recover, configuration/settings file. And I wish there was a unique convention for the way settings are stored. But, too often, it seems like a melting pot of registry settings, .INI, XML or LUA in the program folder OR the user's folder. Personally, I hate the registry for storing settings -- to me, the registry, if any, should be for the OS only. I prefer the *n*x way, seems more secure too, as Josh said.

I very well know that MS Windows' registry main function is to organize in one place (since it's a database, basically) all the settings which used to be scattered all around (in .ini files or whatever) ... But it just doesn't seem like the right way to keep track of software settings anymore. Like some here seem to suggest, the same results could be achieved if all software settings were stored in the user's folder, in clearly identified files and subfolders + in the program's installation folder ? It might use a bit more HD space (but it's less a problem nowadays), but it would be sooooo much easier to backup and restore individual programs' settings** and would insure that everything is portable (I guess I agree with ethyar and josh). No?

**I don't know any easy way to save software’s settings when stored in the registry. And I don't think I'm alone in that (especially since I'm basically an end user, not a programmer): "Restoring parts of the registry is hard because the user cannot easily extract data from backed up registry files. Offline reading and manipulation of the registry (for example from a parallel installed Windows or a boot CD) is not trivial" (wikipedia). BTW : Is there a quick way for a normal user to backup only ONE software with all its registry settings (and only it's own registry settings, not the whole registry), and only restore that software with its settings ?

Ehtyar · « **Reply #10 on:** August 02, 2007, 02:19 AM »

Wow Armando, some registry negatives even i didn't think of, well done

And the answer to your question is a big fat no, unless you consider manually locating and exports your applications registry key(s) (providing they're not disguised of course) and importing them at a later date, after modifying any fully qualified paths etc contained therein easy.

Ehtyar.

justice · « **Reply #11 on:** August 02, 2007, 05:48 AM »

I don't think you should give users the option where to store its settings if your program's users don't know enough about the subject or can't be bothered.

If you create a program that is to be installed (and thus ends up in program files) you might as well store the user settings under the profile. However portable apps are not installed, they probably not live under program files but under c:\portable or c:\utils for example, or on their usb stuck, these folders don't have the restricted security settings, so save the settings with the program

The only problem is if your app can be both. Best use a seperate installer?

f0dder · « **Reply #12 on:** August 02, 2007, 05:55 AM »

Separate installer? Please, no thanks. You'd have two basically identical downloads, except for one little configuration option. It could be an installer option...

Yes, a lot of users are dumb (I know this sounds arrogant, but unfortunately it's true) - the question the application would ask wouldn't be "Do you want to store in %APPDATA% or application folder?", but rather something along the lines of "Are you going to use the program from a removable device, or do you just want a regular installation?" - phrased better by some HR person, and with a proper dialog box that explains the choices better, not just a YES/NO MessageBox.

Josh · « **Reply #13 on:** August 02, 2007, 09:00 AM »

See, this is what I mean. If the application installer prompts you for a portable install, then make the config file an ini file on the removable device, however, if it is not, store them in the users APPDATA folder because that is where it belongs, not in the program files folder.

Armando · « **Reply #14 on:** August 02, 2007, 10:06 AM »

And the answer to your question is a big fat no, unless you consider manually locating and exports your applications registry key(s) (providing they're not disguised of course) and importing them at a later date, after modifying any fully qualified paths etc contained therein easy.
-Ehtyar (August 02, 2007, 02:19 AM)

Thanks Ehtyar. It confirms some things...

moerl · « **Reply #15 on:** August 02, 2007, 11:33 AM »

One thing I never understood is why setups ask me if I'm installing just for myself or for "all users". Why the hell would I care? They need to default to putting application settings into user profile folders by default and skip this question entirely. What advantage could I possibly have from having settings stored for "one user only", which I assume means storing them in the program's install folder?

Eóin · « **Reply #16 on:** August 02, 2007, 12:36 PM »

I think the 'all users' option in a lot of cases just means the shortcuts go into the 'all users' startmenu and other installation related things.

Josh · « **Reply #17 on:** August 02, 2007, 02:37 PM »

The all users option allows settings to be stored in c:\users\default\appdata as opposed to the individual users folder. This is a good policy as well. If you want all users to use the same global settings, this is how to do it.

Ehtyar · « **Reply #18 on:** August 02, 2007, 03:26 PM »

Thanks Ehtyar. It confirms some things...
-Armando (August 02, 2007, 10:06 AM)

You're more than welcome, glad at least one positive thing has come out of this so far

Separate installer? Please, no thanks. You'd have two basically identical downloads, except for one little configuration option. It could be an installer option...
-f0dder (August 02, 2007, 05:55 AM)

I must agree here. I think the PStart installer is probably the example of an ideal portable/not portable installer; the user is given the option of installing to the root of a removable drive, or to program files. When extracted to program files all settings go to the registry, but when extracted to the root of a removable drive, a default xml config is extracted with it.

Ehtyar.

KenR · « **Reply #19 on:** August 02, 2007, 04:41 PM »

I think the program directory, a directory in the Docs and Settings directory or in the registry (typically in CURRENT_USER\SOFTWARE\) is fine as a default, but I wish all programs gave you the option of specifying where you want to keep this information as well as the option to save and restore it. This would make it much easier to maintain program information and settings when you overwrite the OS partition.

Ken

Eóin · « **Reply #20 on:** August 02, 2007, 06:06 PM »

Josh you are right of course. I was just pointing out that numerous programs don't actually listen to that installer option. Once installed they default to their own 'per-user' or 'all users' setting regardless of what you selected when installing.

f0dder · « **Reply #21 on:** August 02, 2007, 06:10 PM »

the user is given the option of installing to the root of a removable drive
-Ehtyar

Hopefully it doesn't limit you to the root of the removable drive? I hate installers that think they know better >_<

Ehtyar · « **Reply #22 on:** August 02, 2007, 10:50 PM »

Indeed i see your point. PStart is a program that you would not use anywhere other than the root of the drive, thus the option is not provided. You could, of course, having selected the portable installation method, move the executable and its config to an alternate folder, though it would not function entirely as advertised.

Ehtyar.

Hirudin · « **Reply #23 on:** August 07, 2007, 02:15 PM »

Personally, I'm the only one who uses my computers, so I'm a big fan of the settings being stored in the program install directory. I try to keep my installed programs and my extracted programs separate. Installed programs go into D:\ProgNew and extracted programs go into D:\ProgNoInst. If I format my C drive all my programs in my D:\ProgNoInst folder still work after reinstalling windows. Also, if I want to move a program from one computer to another (or put it onto a flash drive) I can just copy them out of ProgNoInst, it's VERY convenient!

In situations where multiple users might use the same program it gets a lot more complicated. If user A changes the toolbar layout it should not be changed for user B. Storing the settings in the user folders could be helpful here, but requires switching users in Windows, which is an annoyance. A better solution IMO would be to have users choose a profile to use when the program starts. User A selects "John's Profile" and user B selects "Jane's Profile". If the content of the program is sensitive in some way (e-mail, passwords, whatever) then also have a password for each profile.

In fact, I could see a single user wanting multiple profiles. For example, maybe User A would want a "retouching" profile in Photoshop when he wants to edit an existing photo and a "creation" profile when he's creating a new image. Maybe a "combo" profile as well that gives easy access to all the tools. Switching users would not be a viable option to have access to all these profiles.

Also, having everything in a single directory eases uninstallation; just delete the folder! No registry crap left behind, no "quick start" programs still starting with the computer using up RAM, nothing. Also, there's no worry about gaining rights to other user's folders.

Screenshot - 8_7_2007 , 1_15_01 PM.png

f0dder · « **Reply #24 on:** August 07, 2007, 06:42 PM »

Storing the settings in the user folders could be helpful here, but requires switching users in Windows, which is an annoyance. A better solution IMO would be to have users choose a profile to use when the program starts. User A selects "John's Profile" and user B selects "Jane's Profile". If the content of the program is sensitive in some way (e-mail, passwords, whatever) then also have a password for each profile.
-Hirudin

IMHO the default multi-user config setting should be %APPDATA%, not manual specification of user profile on startup. However, with a flexible config system, it'd be very easy to support both scenarios.