3APA3A, from one hand you are right this may be considered to be
vulnerability in Windows mandatory file locks. But I'm not sure if file
locks in Windows are mandatory. I've never considered "share modes" to
be security feature. You are right that there are bugs related to this
implementation, but... (and here comes my "other hand").

In all scenarios you made assumption that attacker opens file (after all
you used term "preopen") first with FILE_SHARE_WRITE, FILE_SHARE_READ
and FILE_SHARE_DELETE. Subsequent open operation on that opened file
will succeeds, because they don't violates rules placed by first open
operation (sharing for all operations is allowed). So if I want to
create file AND not share it with another processess I should _create_
this file, not _open_ file created by someone else. Of course checking
if file exists is not good solution, because my process is not the only
process in the system and after checking and before creating my file
someone may create this file for me :). In order to be sure I'm creating
not opening file I would probably used CREATE_NEW as value for
dwCreationDisposition attribute AND FILE_SHARE_NONE to prevent others
processess to open my file. So at this moment I see two targets:
- successfuly open file that is already opened with FILE_SHARE_NONE flag,
- create file in that way, that creating file with the same name with
CREATE_NEW will succeed.

Am I correct or I'm missing something?

And one question - which flag for dwCreationDisposition is used for
example by Microsoft World during creating temporary files.