CreateFile 的 SHARE_MODE 参数的超前需要

今天在调试程序时，发现 CreateFile 的 SHARE_MODE 的设置不正常，重读 MSDN 后找到原因。

现在有一个文件，有一个线程会打开文件进入工作状态，需要读/写，会一直保持；另一个线程也要打开文件，但只读少量数据就结束。一开始是这样设定参数的：

工作线程：CreateFile(Path, FILE_READ_DATA | FILE_WRITE_DATA, FILE_SHARE_READ, ...);
查询线程：CreateFile(Path, FILE_READ_DATA, FILE_SHARE_READ, ...);

我以为工作线程中设定 share read 后，查询线程就可以打开了。然而程序运行时却不是如此，查询线程不能打开文件。在确定没有其它代码访问文件后，查 MSDN 发现 CreateFile 关于 SHARE_MODE 有额外的小段说明（下划线标示的文字）：

FILE_SHARE_READ

Enables subsequent open operations on the object to request read access. Otherwise, other processes cannot open the object if they request read access. If the object has already been opened with read access, the sharing mode must include this flag.

后面的一句让我很疑惑。想了一会，认为是这样：如果旧的请求有读权限，那么新的请求要设置 FILE_SHARE_READ。于是修改查询线程的 SHARE_MODE 参数以适应工作线程的写权限：

新查询线程：CreateFile(Path, FILE_READ_DATA, FILE_SHARE_READ | FILE_SHARE_WRITE, ...);

这样一修改，果然可以了。

很奇怪这样一种行为，处于弱势的新请求居然要求旧请求满足它的条件，否则还拒绝打开！！这种要求太严格了。

总之：用 CreateFile 在第二次打开文件时的 SHARE_MODE 参数必须满足已经打开的请求所使用的权限。如果他已经用写权限打开了文件，而我不 share write，则我就拒绝打开文件。