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

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

我们认为授予“用户”组对此文件夹的完全权限可以解决这个问题，但这没有什么区别。即使授予“所有人”完全控制权也无济于事。唯一解决问题的方法似乎是将数据库移动到另一个不是最佳做法的文件夹（例如C:\applicationname）中，或者通过更改快捷方式以管理员权限运行应用程序

我们如何使普通用户能够在C:\ProgramData\文件夹中写入（和创建文件）？还是我们误用了这个文件夹？我的印象是，这是一个正确的地方来放置共享程序数据（对于所有用户）和许多其他应用程序似乎已经把他们的数据放在我的计算机上

更新：

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

如果删除此文件夹，应用程序将正常运行。为什么要创建此文件夹？我能以某种方式防止这种情况吗？可能是因为安装程序没有为C:\ProgramData\中文件夹的用户组授予足够的权限

可能是因为安装程序没有为C:\ProgramData\中文件夹的用户组授予足够的权限

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

当微软推出时，他们需要一种方法让旧的应用程序继续工作，至少在一段时间内。他们提出的是“文件和注册表虚拟化”，即尝试访问（现在是）verboten系统文件夹或注册表项的遗留应用程序将被重定向到它们自己的特定于用户的“虚拟化”资源副本。正如维基百科上的文章所描述的：

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

---

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

我无法重新创建您的问题。我使用“管理员”帐户创建了文件夹“C:\ProgramData\myApp\”，默认权限为“用户”具有只读访问权限。但是，一旦我授予他们对文件夹的“修改”权限，他们就可以打开数据库并创建锁文件。我也不能在自己的机器上复制它，但我可以在两台不同的测试机器和客户的计算机上复制它。我不确定这两台计算机之间有什么区别，因为文件夹权限对我来说似乎相同。因此，如果安装程序授予C:\programData\appname文件夹用户写入权限，这会阻止在VirtualStore中创建“克隆”副本吗？（并因此解决问题？）如果安装程序以提升的权限运行，则应该这样做，因为安装程序将创建一个真实的“appname\”文件夹而不是虚拟的文件夹，然后应用足够的权限，以便其他用户可以对一个“真实”文件夹进行读/写访问。您的编辑肯定正确吗？安装程序怎么可能没有权限？如果它不是以管理员身份运行，它将无法安装该应用程序。还是我误解了？这取决于安装程序具体在做什么。大多数“普通”安装程序需要以提升的权限运行（因此，即使从属于“Administrators”组的帐户运行，也会触发UAC提示），但在您的特定情况下，它可能只是以启动安装程序的用户的普通权限运行。安装程序以管理员用户的身份运行。奇怪的是，我现在无法重现这个问题，所以我仍然很困惑到底是什么原因导致了它。如果我现在尝试重新编程，数据库锁文件只需在VirtualStore文件夹中创建，应用程序就可以正常工作。