Question

My program requires some configuration details to be kept in a .ini file. This program also installs extensions to IE and firefox and i want to read these .ini file from these extensions also. If I kept .ini in "...AppData/Roaming..." the IE extension in protected mode won't be able to read/write. As far as I know only AppData/LocalLow can only be able to read in protected mode. If I am moving all my configuration details to this "...AppData/LocalLoe..." will it work all times? Is this the std way? everything i written is in Vista context, will it work with XP? Win7?

Was it helpful?

Solution

See my answer to this question: How to decide where to store per-user state? Registry? AppData? Isolated Storage?

to quote from there:

Files in the User's "Roaming" folder in Vista or "Application Data" in XP move around with the user - so any settings and data should be stored there.

Files under "Local" and "LocalLow" in vista and "Local Settings" in XP do not, so it's a good place for temp files, things that are tied to the specific computer or data that can be recalculated.

In Vista, as part of the new security features we all know and love, you can have programs running in "low integrity mode" (for example IE in protected mode), those programs are running with reduced privileges and can't access files in the user's profile - except for files under the "LocalLow" folder.

So, in conclusion, files stored in "LocalLow" are inherently insecure and files in "Local"/"Local Settings" are likely to be unavailable in some large companies - so unless you have good reason and know exactly what you are doing go with "Roaming"/"Application Data".

UPDATE:

  1. When profile roaming is used (big cooperate environments) the content of Local and LocalLow can (and will) disappear without notice.
  2. Those are all per-user settings, if your server runs under a diffrent account than the user (for example, system or network) they will get diffrent copies of those folders.

OTHER TIPS

To get folder path for program data you should use WinAPI:

wchar_t path_buf[MAX_PATH];
SHGetFolderPath( NULL, CSIDL_COMMON_APPDATA, NULL, SHGFP_TYPE_CURRENT, &path_buf[0] );

In Windows Vista function SHGetFolderPath was replaced with SHGetKnownFoldedPath. That older function is now simply a wrapper for SHGetKnownFolderPath.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top