(编辑：请注意,我们无法重现行为.我们目前只有一个日志文件,指示CFile :: Write所在的源行,并包含错误ERROR_ACCESS_DENIED！)
(编辑：该文件位于本地驱动器上,它实际上是一个文件而不是目录.)
现在,WriteFiles’s documentation并没有真正帮助,尝试使用简单的测试应用程序会产生以下结果：
>如果调用未写入的文件句柄(即打开仅供读取),则WriteFile将导致ERROR_ACCESS_DENIED.
>如果是,则不会导致ERROR_ACCESS_DENIED
>句柄无效或文件根本不打开
>在进程打开文件后,将修改文件的访问权限或写保护标志. (如果在打开文件之前修改了这些文件,那么我们永远不会使用WriteFile,因为打开文件会失败.)
>该文件以某种方式被另一个进程/句柄锁定(这最多会导致错误32 ERROR_SHARING_VIOLATION).
这让我们看到了这种情况,如果文件实际上是用read标志而不是write标志打开的,那么这个调用的唯一可能性就是失败了.但是,看看我们的代码,这似乎不太可能. (由于我们的跟踪,我们可以确定WriteFile失败并且我们可以确定错误是ERROR_ACCESS_DENIED,我们不能100.1％确定打开标志,因为这些没有被追踪.)
是否存在WriteFile(CFile :: Write)会导致ERROR_ACCESS_DENIED的其他已知情况？
注意：另外澄清这个问题的背景：
>文件已打开,因此它不能是目录或某些目录
>我执行的所有测试都表明文件打开时无法删除,因此在调用WriteFile时文件应该仍然存在
>该文件位于本地驱动器上,而不是位于网络驱动器上.
我应该补充一点,我们在WIndows XP sp3上运行,应用程序是用Visual Studio 2005编译的.
解决方法
What causes WriteFile to return
ERROR_ACCESS_DENIED?
我在问题中说
- WriteFile will cause
ERROR_ACCESS_DENIED if it is called
for a file handle that is not opened
for writing (i.e. is opened for
reading only).
在为打开的标志和另一个事件添加进一步的日志记录之后,结果证明这是正确的.打开标志的日志记录显示,在错误点,文件对象是用CFile :: modeRead打开的,因此我们得到了ERROR_ACCESS_DENIED.
还没有发现哪个奇怪的代码路径导致这个,但这只是表明：永远不要相信自己的代码. 原文链接：https://www.f2er.com/c/118804.html
