Cannot create files in C:\ProgramData\ even after granting Users group full permission

Question

We have an application which tries to write to an Access database (.mdb) in the C:\ProgramData\ folder. On computers with UAC enabled we find that accessing the database fails as it seems it cannot create the lock file. It seems that by default (and perhaps due to UAC) users (including admins) don't have permission to write to the applications folder by default.

We thought that granting the "Users" group full permissions to this folder would fix the problem, however it makes no difference. Even granting "Everyone" full control still doesn't help. The only thing which fixes the problem seems to be to move the database into another folder (eg C:\applicationname) which is not best practice OR running the application with Administrator privileges by changing the shortcut.

How can we make it so normal users can write (and create files) in the C:\ProgramData\ folder? Or are we misusing this folder? I was under the impression that is the correct place to put shared program data (for all users) and many other applications seem to have put their data there on my computer.

Update:

I have found that a clone copy of the database has been put in to following folder: C:\Users\\AppData\Local\VirtualStore\ProgramData\

If I delete this folder, the application then performs normally. Why was this folder created? Can I prevent this somehow? Could it be because the installer does not give adequate permissions to the Users group on the folder in C:\ProgramData\ ?

Answer 1

Could it be because the installer does not give adequate permissions to the Users group on the folder in C:\ProgramData\ ?

Actually, it is more likely that the installer did not have sufficient permissions to mess with "C:\ProgramData\" directly. (I thought that this scenario sounded familiar....)

When Microsoft introduced UAC they needed a way for older applications to continue working, 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 would be redirected to their own user-specific "virtualized" copy of those resources. As the Wikipedia article on UAC describes it:

Applications written with the assumption that the user will be running with administrator privileges experienced problems in earlier versions of Windows when run from limited user accounts, often because they attempted to write to machine-wide or system directories (such as Program Files) or registry keys (notably HKLM).[4] UAC attempts to alleviate this using File and Registry Virtualization, which redirects writes (and subsequent reads) to a per-user location within the user's profile. For example, if an application attempts to write to a directory such as "C:\Program Files\appname\settings.ini" to which the user does not have write permission, the write will be redirected to "C:\Users\username\AppData\Local\VirtualStore\Program Files\appname\settings.ini". The redirection feature is only provided for non-elevated 32-bit applications, and only if they do not include a manifest that requests specific privileges.[13]

If your installer requests "Run as administrator" privileges then you should be able to avoid this issue.