即使授予用户组完全权限,也无法在C:\ ProgramData \中创建文件

Question

我们有一个应用程序尝试写入C:\ ProgramData \文件夹中的Access数据库(.mdb).在启用了UAC的计算机上,我们发现访问数据库失败,因为它似乎无法创建锁定文件.似乎默认情况下(也许是由于UAC)用户(包括管理员)默认没有写入应用程序文件夹的权限.

我们认为授予"用户"组对此文件夹的完全权限可以解决问题,但这没有任何区别.即使授予"每个人"完全控制权仍然没有帮助.解决问题的唯一方法似乎是将数据库移动到另一个文件夹(例如C:\ applicationname),这不是最佳实践,或者通过更改快捷方式以管理员权限运行应用程序.

我们怎样才能让普通用户在C:\ ProgramData \文件夹中编写(和创建文件)？或者我们滥用此文件夹？我认为这是放置共享程序数据的正确位置(适用于所有用户),许多其他应用程序似乎已将其数据放在我的计算机上.

更新:

我发现数据库的克隆副本已放入以下文件夹:C:\ Users \\ AppData\Local\VirtualStore\ProgramData \

如果我删除此文件夹,则应用程序将正常执行.为什么要创建此文件夹？我能以某种方式阻止这种情况吗 可能是因为安装程序没有为C:\ ProgramData \中文件夹上的Users组提供足够的权限？

Answer 1

是否是因为安装程序没有为 C:\ProgramData\ 中的文件夹的 Users 组授予足够的权限？

实际上，更有可能的是安装程序没有足够的权限直接破坏“C:\ProgramData\”。（我觉得这个场景听起来很熟悉……）

当 Microsoft 引入UAC时，他们需要一种方法让旧应用程序能够继续工作，至少在一段时间内。他们提出了“文件和注册表虚拟化”，其中尝试访问（现在）禁止的系统文件夹或注册表项的遗留应用程序将被重定向到这些资源的用户特定的“虚拟化”副本。正如 Wikipedia 关于UAC的文章所描述的那样：

假设用户将以管理员权限运行而编写的应用程序在早期版本的 Windows 中从有限的用户帐户运行时会遇到问题，通常是因为它们试图写入计算机范围或系统目录（例如Program Files）或注册表项（尤其是 HKLM）。[4] UAC 尝试使用文件和注册表虚拟化来缓解这种情况，它将写入（以及后续读取）重定向到用户配置文件中的每个用户位置。例如，如果应用程序尝试写入用户没有写入权限的目录，例如“C:\Program Files\appname\settings.ini”，则写入将被重定向到“C:\Users\username” \AppData\Local\VirtualStore\Program Files\appname\settings.ini”。重定向功能仅适用于非提升的 32 位应用程序，并且仅当它们不包含请求特定权限的清单时才提供。[13]

如果您的安装程序请求“以管理员身份运行”权限，那么您应该能够避免此问题。