On a couple of occasions, we?ve been surprised at the outcome of the following test:
Open an existing file via FltCreateFileEx2 (or similar) with:
DesiredAccess = FILE_READ_DATA
ShareAccess = FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE
Flags = IO_IGNORE_SHARE_ACCESS_CHECK
While the file handle is still open, open the same file with:
DesiredAccess = FILE_WRITE_DATA
ShareAccess = 0
Flags = 0
We expect the second open to fail with STATUS_SHARING_VIOLATION, since the file is already open for READ and the sharing flags are incompatible.
However, the second open succeeds. We find the same regardless of the desired access of the second open ? FILE_READ_DATA and DELETE also work. We?ve reproduced this on Windows 7 SP1 as well as Windows 10 SP3.
When I finally decided to post my puzzlement to NTFSD, the site was down due to the OSR office move. Later I found a similar observation, without explanation:https://www.osronline.com/showthread.cfm?link=152866
As it turns out, if IO_IGNORE_SHARE_ACCESS_CHECK is passed in, IoCheckShareAccess does not update the counts in the SHARE_ACCESS struct of the FCB. So, subsequent opens are not affected by the access permissions or share access.
Given this undocumented behavior, I wrote a blog post. I recently came across quite a complicated approach to avoid sharing violations -- this way is much easier and should be made more obvious.https://needleinathreadstack.wordpress.com/2018/04/09/io_ignore_share_access_check
Feedback is most welcome. Thanks,