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