Cannot create files in C: \ ProgramData \ even after granting full permission to a group of users

Question

We have an application that is trying to write to the Access database (.mdb) in the C: \ ProgramData \ folder. On computers with UAC enabled, we find that access to the database fails because it seems that it cannot create a lock file. Apparently, by default (and possibly due to UAC), users (including administrators) are not allowed to write to the default application folder.

We thought that granting full permissions to the Users group to this folder would fix the problem, but it doesn’t matter. Even giving full control to “Everything” still doesn't help. The only thing that fixes the problem seems to be to move the database to another folder (for example, C: \ applicationname), which is not best practice or it runs the application as administrator, changing the shortcut.

How can we make it possible for ordinary users to write (and create files) in the C: \ ProgramData \ folder? Or are we using this folder incorrectly? I got the impression that this is the right place to host the general program data (for all users), and many other applications seem to place their data on my computer.

Update:

I found that a cloned copy of the database was placed in the following folder: C: \ Users \\ AppData \ Local \ VirtualStore \ ProgramData \

If I delete this folder, the application will work fine. Why was this folder created? Can i prevent this? Maybe due to the fact that the installer does not give the appropriate rights for the Users group in the folder in C: \ ProgramData \?

Answer 1

Could this be due to the fact that the installer does not provide the appropriate rights for the Users group in the folder in C: \ ProgramData \?

In fact, most likely, the installer did not have sufficient permissions to mess with "C: \ ProgramData". (I thought this script sounds familiar ....)

When Microsoft introduced UAC , they needed a way for older applications to continue to work, at least for a while. What they came up with was “File and Registry Virtualization,” where legacy applications that tried to access (now -) verboten system folders or registry entries were redirected to their own “virtualized” copy of these resources for each user. As the Wikipedia article on UAC says:

Applications written with the assumption that the user will be running as an administrator experience problems in earlier versions of Windows when running from limited user accounts, often because they tried to write to machine or system directories (for example, program files) or registry keys (in particular, HKLM). [4] UAC is trying to mitigate this by using file and registry virtualization, which redirects entries (and subsequent reads) to each user's location in the user profile. For example, if an application tries to write to a directory such as "C: \ Program Files \ appname \ settings.ini", to which the user does not have write permission, the recording will be redirected to "C: \ Users \ username" \ AppData \ Local \ VirtualStore \ Program Files \ appname \ settings.ini ". The redirection function is provided only for non-extended 32-bit applications and only if they do not contain a manifest requesting certain privileges. [13]

If your installer asks for Run As Administrator privileges, you can avoid this problem.