我们有一个应用程序尝试写入C：\ ProgramData \文件夹中的Access数据库（.mdb）。在启用了UAC的计算机上，我们发现访问数据库失败，因为它似乎无法创建锁定文件。似乎默认情况下（也许是由于UAC）用户（包括管理员）默认没有写入应用程序文件夹的权限。
我们认为授予“用户”组对此文件夹的完全权限可以解决问题，但这没有任何区别。即使授予“每个人”完全控制权仍然没有帮助。解决问题的唯一办法似乎是将数据库移动到另一个文件夹（例如C：\ applicationname），这不是最佳实践，或者通过更改快捷方式以管理员权限运行应用程序。
我们怎样才能让普通用户在C：\ ProgramData \文件夹中编写（和创建文件）？或者我们滥用此文件夹？我认为这是放置共享程序数据的正确位置（适用于所有用户），许多其他应用程序似乎已将其数据放在我的计算机上。
更新
我发现数据库的克隆副本已放入以下文件夹： C：\用户\\应用程序数据\本地\ VirtualStore \ ProgramData \
如果我删除此文件夹，则应用程序会正常执行。为什么要创建此文件夹？我能以某种方式阻止这种情况吗可能是因为安装程序没有为C：\ ProgramData \中的文件夹上的Users组提供足够的权限？
答案 0 :(得分：4)
可能是因为安装程序没有为C：\ ProgramData \中的文件夹上的Users组提供足够的权限吗？
实际上，安装程序更有可能拥有足够的权限来直接搞乱“C：\ ProgramData \”。 （我认为这个场景听起来很熟悉......）
当Microsoft引入UAC时，他们需要一种方法让旧应用程序继续工作，至少在一段时间内。他们提出的是“文件和注册表虚拟化”，其中试图访问（现在 - ） verboten 系统文件夹或注册表项的旧应用程序将被重定向到他们自己的用户特定“虚拟化”副本这些资源。正如关于UAC的维基百科文章所描述的那样：
假设用户将以管理员权限运行而编写的应用程序在从有限的用户帐户运行时在早期版本的Windows中遇到问题，通常是因为他们试图写入机器范围或系统目录（例如程序文件）或注册表项（特别是HKLM）。[4] UAC尝试使用文件和注册表虚拟化来缓解此问题，将写入（和后续读取）重定向到用户配置文件中的每个用户位置。例如，如果应用程序尝试写入用户没有写入权限的目录，例如“C：\ Program Files \ appname \ settings.ini”，则写入将重定向到“C：\ Users \ username” \ AppData \ Local \ VirtualStore \ Program Files \ appname \ settings.ini“。重定向功能仅适用于非提升的32位应用程序，并且仅在它们不包含请求特定权限的清单时才提供。[13]
如果您的安装程序请求“以管理员身份运行”权限，那么您应该可以避免此问题。