保存文件到挂载的可写的磁盘，系统弹出另存为框，再次尝试保存，保存成功

[Donoy]

Check List

• I checked my issue doesn't exist yet
• My issue is valid with mirror default sample and not specific to my user-mode driver implementation
• I can always reproduce the issue with the provided description below.
• I have updated Dokany to the latest version and have reboot my computer after.
• I tested one of the last snapshot from appveyor CI

Describe the bug

现象：Notepad程序保存文件到挂载的可写的磁盘，系统弹出另存为框，再次尝试保存保存成功。观察到如果在文件浏览器-查看-打开预览窗格时，该问题就会出现，关闭不会出现。见问题录屏附件。

目前分析到：通过procmon监控分析，确实notepad写该文件系统返回了 ACCESS_DENY，应该就是这个导致Notepad程序认为存储位置不可写，从而导致弹出另存为框。

分析代码：目前怀疑和这段代码处理有关系

阅读这段代码，感觉是用来检查文件的打开共享权限检查的，我将-EACCESS注释掉，修改为和else一样的逻辑后测试发现该问题就不出现了，修改后的如下：

想咨询一下这段代码可以这样屏蔽处理吗？这种情况有其他的办法处理吗？希望能够收到你的回复，感谢！

To Reproduce
见问题录屏

Expected behavior
见问题录屏

Logs
Please attach in separate files: mirror output, library logs and kernel logs.
In case of BSOD, please attach minidump or dump analyze output.

Environment:

• Windows version: win10 1809
• Processor architecture: x64
• Dokany version: 2.2.0.1000
• Library type (Dokany/FUSE): FUSE

Additional context
Add any other context about the problem here.

问题录屏.zip

[Liryna]

@Donoy Thanks for the detail explanation and the recording!

I think here we need to find out whether we really have a legit sharing error or it is a bug.
Could you look with procmon which Create are still active on the file (Create that were not closed) and what are their sharing permission ?
You can also print here the sharing value of all active handle and confirm if it matches what you see in procmon
Then print the final share and required_share(access_mode) to see how they conflict.