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