如何在 VB6 中设置非管理员用户的文件权限？
我有一个用 vb6 编写的旧更新程序，它以管理员身份运行。但是，由于它以管理员身份运行，因此它下载和保存的所有文件对于其他用户都是只读的。即使是公共场所的文件，例如共享应用程序数据文件夹（这是我保存相关文件的位置）。
我很幸运，在“兼容 vista”的版本发布之前就发现了这个。 Vista 通过将非管理员写入和将来的读取重定向到某种“虚拟”文件夹来隐藏问题。但下次更新可能会替换该文件，非管理程序仍会转到虚拟文件夹并使用旧文件。
作为管理员用户，我如何允许其他用户完全控制我在 vb6 中编写的文件？
I have an old update program written in vb6, which runs as admin. However, because it runs as admin, all the files it downloads and saves are read-only to other users. Even files in public places like the shared application data folder (which is where I'm saving the files in question).
I'm lucky I found this before the 'vista-compatible' release. Vista hides the problem by redirecting non-admin writes and future reads to a sortof 'virtual' folder. But the next update may replace the file, and the non-admin program will still go to the virtual folder and use the old file.
As the admin user, how do I allow other users full control of files I write in vb6?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我这样做的方法是让它成为安装人员的责任。
使用 VSI 1.1 为您的应用程序创建安装程序 MSI。在 CommonAppDataFolder 下创建应用程序数据文件夹。
作为构建后步骤，运行脚本来执行以下操作：
FILE_ALL_ACCESS。就是这样。
您可以这样做，或者使用 VSI 1.1，然后使用 Orca 编辑 MSI，或者可能使用第 3 方 MSI 创作工具，这些条目将通过其 GUI 进行设置，并可以保存在安装程序项目中。我只使用在每次 VSI 1.1 构建后运行的一个小 WSH 脚本。
据我所知，这是根据 Windows 应用程序指南完成此类操作的推荐方法。如果您的需求更高级，您可以使用多个子目录或子子目录，其中一些允许完全访问，一些允许只读等。
您的程序可以使用 Shell Automation 对象或通过调用 Shell32 作为标准 DLL（使用 Declare Function 或TLB）。
The way I do this is to make it an Installer responsibility.
Use VSI 1.1 to create an Installer MSI for your application. Create an application data folder under CommonAppDataFolder.
As a post-build step run a script to perform the following:
FILE_ALL_ACCESSfor Everyone.That's about it.
You can do it this way, or use VSI 1.1 and then edit the MSI using Orca, or probably by using a 3rd party MSI authoring tool these entries will be settable via its GUI and can be saved in the Installer project. I just use a small WSH script I run after each VSI 1.1 build.
AFAIK this is the recommended way of accomplishing such things according to Windows application guidelines. If your needs are fancier you might use multiple subdirectories or sub-subdirectories some allowing full access, some read-only, etc.
Your program can locate the folder using Shell Automation objects or by calling Shell32 as a standard DLL (using Declare Function or a TLB).
不一定是谁写的文件，而是他们写到哪里。默认情况下，程序文件文件夹及其子文件夹对所有标准用户都是只读的。尝试使用“所有用户应用程序数据”文件夹。
这对于 VB6 来说有点棘手，因为它根本不是为 Vista 设计的。一些相关的文件夹被重新命名，我无法知道如何让 vb6 为您提供您想要的确切文件夹，除非使用“声明函数”别名直接调用 Windows API。
因此，我知道找到合适位置的最简单可靠的方法是使用
%ALLUSERSPROFILE%环境变量。在 XP 上默认返回“C:\Documents and Settings\All Users”，在 Vista 上默认返回“C:\ProgramData”。从那里您可以查找“应用程序数据”文件夹。它不会在那里，而且在 Vista 上您也不需要它，但如果它不存在，创建一个也不会造成任何损害。这为您在两个系统上提供了一致的文件夹结构，您可以从中为您的应用程序创建一个子文件夹以用作工作空间。最后要注意的是：这对于 Vista 来说并不是一个新的变化。默认情况下，Program Files 文件夹对于标准用户始终是只读的。 XP 的工作方式相同。只是这么多人在 XP 中以管理员身份运行，你也许可以逃脱惩罚。
It's not necessarily who writes the file, but where they write it to. The program files folder and it's sub folders are read-only to all standard users by default. Try using the All Users Application Data folder instead.
This is a little tricky for VB6, since it was not at all designed with Vista in mind. Some of the relevant folders were re-named and there's no way I know to get vb6 to give you the exact folder you want short of using a "Declare Function" alias to call directly into the windows API.
So the easiest reliable way I know to find a suitable location is to use the
%ALLUSERSPROFILE%environment variable. That returns "C:\Documents and Settings\All Users" by default on XP and "C:\ProgramData" by default on Vista. From there you can look for an "Application Data" folder. It won't be there and you don't need it on Vista, but creating one if it doesn't exist won't hurt anything. That gives you a consistent folder structure on both systems from which you can create a sub folder for your app to use as a work space.And one final note: this isn't a new change for Vista. Program Files folders have always been read-only to standard users by default. XP worked the same way. It's just that so many people run as administrators in XP you might be able to get away with it.