unfortunately i not wait for such result… may be i too bad explain
indeed it DOES matter. While it is true that the Native API gets called eventually, your entire issue (it seems to me) is with how Win32 handles the edge >cases. If you limit your work to the Native NT API (in user mode or kernel mode, “no matter”) then I think you’ll find things much more clear.
NO. you mistake here. this is not win32 issue. nothing is changed if we call direct native api. and handle direct NTSTATUS but not wrong (not rarely) win32 error. may be my mistake that i post both versions. and i agree that Native NT API much more clear , but here problem not in win32 layer.
and here not problem in file system implementations at all too. the problem in I/O manager kernel code - i say this all time. problem in how it handle FAST IO case. at some (LockFile) point I/O manager post completion to IOCP, even if error status returned. at another point (Unlock) - I/O manager -complete request without IOCP (even if STATUS_SUCCESS returned). not driver, but I/O itself ! simply WRK-v1.2 (i paste links) for understand src of problems
Byte range locks are another odd case, and I suspect how they behave will vary from file system to file system.
again - this not file system problem - how it handle request, but I/O manager problem - how it complete request.
and Directory Change Notification here unrelated at all. i nothing write about it, and perfect know how it work and not once use it in async mode, but here no problems.
simply look win
ok. sorry for all