> >Mapping = CreateFileMappingW(Handle, 0, PAGE_READWRITE, 0, FileSize, 0);
>
> So it is more a "case" not handled by dokan rather that all memory mapped not handled ? Is this made in purpose just to remove dokan from the bench ?
I do not understand this.
Are you familiar with how memory mapping works on Windows? CreateFileMappingW is it. If that API fails you do not have memory mapping.
Furthermore I challenge you to show me how Dokany/MEMFS makes this API fail. If you find such an issue I promise to fix it and re-run the tests.
>The lock exists on WinFsp/MEMFS. It is just taken in a different place:
It changes nothing on what I said. You added it on dokan side without reason and not on winfsp memfs.
I added it on Dokan side, because I needed to protect the Dokany/MEMFS data structures against corruption. On the WinFsp side this lock is taken automatically as a convenience (although one can remove it if the file system can cope by using a custom "operation guard" (FspFileSystemSetOperationGuard) -- it is not needed for WinFsp operation).
The exact same lock is taken on both sides. There is no unfair advantage to WinFsp. If you design a file system that takes no locks and works on both WinFsp and Dokany, I will be happy to run the tests against that file system.
> A pull request will not change that a real application on a non-virtual machine will not see the difference.
All the "real application" has to do is to open a file and issues some I/O. Just because Dokany does not cache I/O it will be 9x-10x slower than WinFsp.