notepad.exe return STATUS_SHARING_VIOLATION when save

[NatsuKageX]

This appears in my windows server 2019 system when using notepad.exe in dokan disk. I have tried both mirror and memfs sample and still appear. when I first time opening a txt file and edit then save in dokan disk, it return STATUS_SHARING_VIOLATION, I ignore this error and the next time I save the file, it success. Reproducing this when I close the file and reopen it. I used filespy.exe and check the dokan sys log, it shows that create irp faild in DokanCheckShareAccess function but there is no other process opening the file.

failed:

success

[NatsuKageX]

I found more details about this bug. When I open the txt by notepad.exe and keep it opening, then I tried open the same txt file by generic read/generic write immediately, it returns STATUS_SHARING_VIOLATION. After few seconds, I retried open the txt file by the same desired access and share access, it succeed. Looks like there are some share access status of io manager are not synced immediately.

[Liryna]

Hi @NatsuKageX , I just tried on a fresh Windows Server 2019 with the dokany 2.3.0 memfs and couldn't reproduce the issue. Have you checked if there could be any other software like antivirus that could prevent the correct usage of Dokany ?
Could you share a capture of Procmon that has the repro of your issue ?

[NatsuKageX]

Yes. I also test it in several Windows Server 2019 systems, it only appears in two of them. I have checked that there is no antivirus and minifilters in dokany volume. The reproduce method of this issue is still not clearly.

[NatsuKageX]

Additionly, a new error occurs during my test, the notepad shows "cant open file, please check if there ars disks in the drive". Seems that occurs because of the paging read return sharing_violation. If I open the file with generic read/generic write by filemock.exe and keep opening, then open the same file by notepad.exe, the paging read irp will also failed with sharing_violation. Does not appears in the ntfs volume.
Capture is below:

dokany log:

ntfs log:

[NatsuKageX]

I have found the reproduce method as same as the closed issue #1269, when I open the preview of explorer, it will always failed when first time save the txt file.

[NatsuKageX]

I have found that problem is related to oplock. When I create a file with oplock(which the explorer preview does), then open the same file with read/write access in other process(which the notepad does), then the notepad create irp will pending until explorer cleanup the file. In ntfs and fastfat, the fsd will call IoRemoveShareAccess before FsRtlCheckOplock, which ensure the notepad create could success when the pending irp resume. But in dokany, the FsRtlCheckOplock is called in DokanDispatchCleanup, and the IoRemoveShareAccess is called in DokanExecuteCleanup which is behind of the FsRtlCheckOplock.
Should we move the IoRemoveShareAccess from DokanExecuteCleanup to the DokanDispatchCleanup before calling FsRtlCheckOplock like fastfat?

[Liryna]

Hey @NatsuKageX sorry for the long delay! I looked into fastfat and you are right they do remove the shared access before oplock check. What do you think about making the oplock check sync and move it to the other completion function ? Could you confirm that it fixes your issue / repro case ?
4bf329d

[NatsuKageX]

Yes, it does fix this issue. @Liryna