在 Windows 上模拟文件错误（例如 ERROR_ACCESS_DENIED）
出于测试和开发目的，最好以某种方式模拟对本地文件的（虚假）文件访问错误。例如，即使应用程序已使用适当的限制性共享标志正确打开了文件，仍然可能会尝试访问该文件（通过任何 Win32 API 函数或您最喜欢的框架，它们在内部只会调用任何Win32 API 函数）可能会失败。
我能够找到的唯一例子是机器上的病毒扫描程序，但我想可能还有其他原因。 （在这个问题的评论中，卢克提到有关“文件系统过滤器驱动程序”的一些内容。）
FWIW，我知道一些可能性为了“模拟”文件问题，我不考虑好的解决方案，要么是因为它们需要大量的手动工作，要么是因为它们不适合每个应用程序/文件：
- 将文件放在网络驱动器上或可移动存储设备 - 这样您可能会弄乱设备（拔掉插头，磁盘已满，...）。
- 在 Process Explorer 中打开应用程序进程并关闭所需文件的句柄进行测试。
因此，真正的问题是，是否有任何（（半）自动化）工具可能会扰乱文件访问（在 NTFS 驱动器上），即使应用程序已经使用适当的方式打开了文件（对于应用程序） ）共享标志。
For testing and development purposes, it would be nice to somehow simulate (spurious) file access errors to local files. For example, even if an application has correctly opened a file with the appropriate restrictive sharing flags, it still can happen that an attempt to access the file (through any of the Win32 API functions or your favourite framework, which internally will just call any of the Win32 API functions) can fail.
The only example I ever was able to track down was the virus scanner on a machine, but I guess there could be other reasons. (In this question's comment, Luke mentions something about "File system filter drivers".)
FWIW, I know of a few possibilities to "simulate" file problems, that I do not consider good solutions, either because they require to much manual work or because they don't fit for every app/file:
- Place a file on a network drive or removable storage device - that way you can just mess up the device (unplug, disk-full, ...).
- Open the application process in Process Explorer and close the handle of the file you want to test.
So the question really is if there are any ((semi)automated) tools that can mess up file access (on an NTFS drive) even though an application has already opened a file with appropriate (for the app) sharing flags.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Holodeck 声称允许 Win32 API 挂钩，这将使您能够根据需要操纵返回代码故障注入。
如果您感兴趣的 API 集已明确定义，您可能可以使用 这里。
Holodeck purports to allow Win32 API hooking, which would enable you to manipulate return codes as needed for Fault Injection.
If your API set of interest is well-defined, you could probably do this yourself using the Import Address Table approach described here.