Windows 8: Application is not able write to C:\ProgramData\

Question

I'm porting my application on Windows 8. Program uses path

C:\ProgramData\MyProgramName\

for storing backups. It works good on Windows 7, but it got "Access Denied" when I run it on Windows 8.

What is the proper way and place to store my program's backups (not related to any particular user) ?

Answer 1

I see many programs storing their non-user related application data in the common application folder. Ok, actually what they do is create a folder inside the common application folder to store their data.

To get the path to the common application folder, you can call the SHGetFolderPath function with CSIDL_COMMON_APPDATA as the folder id. If don't have to support anything earlier than Windows Vista then you can call the SHGetKnownFolderPath function instead, and pass FOLDERID_ProgramData as the known folder id.

Ah! I did not know that the common application folder is not-writeable by normal users. Luckily there appears to be a recommended solution. See this article on MSDN, Data and Settings Management which states the following "If an application requires normal Users to have write access to an application specific subdirectory of CSIDL_COMMON_APPDATA, then the application must explicitly modify the security on that sub-directory during application setup. The modified security must be documented in the Vendor Questionnaire."

Answer 2

C:\ProgramData has security settings that prevent standard user from writing there. This is not new in Windows 8, Windows 7 was the same, and the equivalent folder on Vista is also secured in this way. Perhaps your Windows 7 environment has UAC disabled, or perhaps you have secured C:\ProgramData or C:\ProgramData\MyProgramName to permit write access to standard user.

There are a couple of approaches to the use of this folder. Some applications write there only during installation whilst the installer process is running elevated. Then the application itself, which runs as standard user, can read, but never attempts to write.

Another approach is for the installer to create a sub folder of C:\ProgramData that is secured to allow write access for standard user, or whatever user/group that you the developer deem appropriate.