0

I can tell you where non-admin's aren't allowed to write to:

Environment::GetFolderPath(Environment::SpecialFolder::ApplicationData) + "\\Config.ini";
Environment::GetFolderPath(Environment::SpecialFolder::CommonApplicationData) + "\\monitorService\\Config.ini";
Environment::GetFolderPath(Environment::SpecialFolder::ProgramFiles) + "\\monitorService\\Config.ini";

I had high hopes for Environment::SpecialFolder::CommonApplicationData but sadly that one's off limits for ordinary limited users also. I need a common, easy to, err, know & find, directory where I can load configuration data from and save it to. I suppose I could countenance per-user config files, but I'd rather keep things as simple as possible.

Could I perhaps have my installer set aside some area of the registry or filesystem for universal access? I use Innosetup and .NET code to install. I've noticed (IRC) firefox fills up "Application Data" folders for named and default users so I guess that's another possibility. As the config data is needed by the service it might be too much trouble to store a couple of short strings and ints in anything other than the registry.

Community
  • 1
  • 1
John
  • 6,433
  • 7
  • 47
  • 82
  • I dont understand. What is the problem in using the registry exactly? This is what it was designed for – carpii Oct 24 '11 at 03:40
  • Is there a reason that everybody should have the same configuration? In most contexts the end-user won't expect or want this behaviour, and it also introduces potential security issues. – Harry Johnston Oct 25 '11 at 01:29

1 Answers1

0

Since no one has answered I may as well posit my solution while I go about the implementation.

Limited users only have write access to HKCU. This is the same as using the file system- some user specific branches will be writable. It is hassle to have to check for write access to the global config file at the right time the user logs on and then delegate to user-local config if it throws, but that is what must be done. Being easier to defrag and less of a performance hit I will attempt using the FS before HKCU.

John
  • 6,433
  • 7
  • 47
  • 82
  • That's it solved. I tested for write access to `CommonApplicationData` and fell back to using `ApplicationData` if needed. Interestingly the fall back has not been necessary, perhaps the way I programmatically created a sub folder under `CommonApplicationData` had something to do with it.. – John Oct 25 '11 at 14:50