Identifying exact type of file info call from .NET wrapper

[Codeweep]

Hello Dokan-dotnet contributors 🖐️

i have been using the Dokan .NET wrapper for a while now and never encountered any issues in its normal operation. That has changed since last week though - it's not strictly an issue with Dokan but with how Dokan plays together with another app installed on a clients' computer. The app in question is an old Java application written by a third party unwilling to provide updates to optimize performance - or even security patches (as far as I can tell they are still using exploitable Log4J versions as well).

The issue now is that for some reason the app freezes shortly for every document / directory fetched from the virtual drive and takes ages to display. The previous drive that supplied the filesystem was a WebDAV share accessed through the Microsoft WebDAV Redirector (WebClient) available to install through Windows Server-Manager. That drive showed the following behaviour (logged by Procmon) for the given requests by this app: Note the 'NOT IMPLEMENTED' result for the QueryNetworkOpenInformationFile request.

With our new Dokan drive the same call is returned with SUCCESS supplying the information requested by the app.

For some reason the application then waits for multiple hundred milliseconds before requesting information for another file. And that repeats for every file in every structure. Not being able to contact the developers of the other app i would need to somehow fix this.

So as the title says - can I somehow identify that GetFileInformation was called by QueryNetworkOpenInformationFile instead of QueryBasicInformationFile to mimic the old drives behaviour and hopefully avoid the app from waiting for X seconds everytime a directory is opened?

Maybe i will need to open another issue regarding something else but I'm gonna continue testing on that front before bothering you. I really appreciate all the work put into this project and enjoy working with it - keep it up and thanks for sharing any ideas 👍

[Liryna]

Hi @Codeweep ,

I would have guessed this is the path it takes when QueryNetworkOpenInformationFile is called but this does not return not implemented so maybe it is a before that call (hidden inside QueryNetworkOpenInformationFile. https://github.com/dokan-dev/dokany/blob/5c25310803d116ffa14b101595fea2cd927e4f15/dokan/fileinfo.c#L392-L397

If double click in Procmon, it might some time show you the callstack where it got this status.

Otherwise the best is to enable kernel logs and see what is going on and where does this status comes from. Release build with debug logs enable should be enough https://github.com/dokan-dev/dokany/wiki/How-to-Debug-Dokan#logs-on-release-build but sometimes you would need debug build if you can’t find the source.

the app from waiting for X seconds everytime a directory is opened do you see call completing in procmon after it resume ?

[LTRData]

Hi @Codeweep ,

I would have guessed this is the path it takes when QueryNetworkOpenInformationFile is called but this does not return not implemented so maybe it is a before that call (hidden inside QueryNetworkOpenInformationFile. https://github.com/dokan-dev/dokany/blob/5c25310803d116ffa14b101595fea2cd927e4f15/dokan/fileinfo.c#L392-L397

If double click in Procmon, it might some time show you the callstack where it got this status.

Otherwise the best is to enable kernel logs and see what is going on and where does this status comes from. Release build with debug logs enable should be enough https://github.com/dokan-dev/dokany/wiki/How-to-Debug-Dokan#logs-on-release-build but sometimes you would need debug build if you can’t find the source.

the app from waiting for X seconds everytime a directory is opened do you see call completing in procmon after it resume ?

I think you might have misunderstood. He seems to be talking about a case where Dokan completes QueryNetworkOpenInformationFile with SUCCESS, while the previous implementation that they used with WebDAV failed the same requests with "not implemented". The issue here is apparently that to workaround some strange behaviour in the Java application, they need to test failing the requests in a similar way with Dokan and see if that helps.

I would say that it should be fairly easy with a small modification to the driver code and build a test version of the driver that they could try to see if it helps.

[Liryna]

Oh my bad. I wonder if we shouldn't actually fail this request if this is not a network device.

For testing, just changing the library to force return that status on that call is enough.

[LTRData]

This leads me to thinking in another direction. @Codeweep , have you tried to create the Dokan file system both as a network drive and a local drive? Any differences to this behaviour between the two mount modes?

[Codeweep]

Sorry for causing some confusion regarding the old and new drive..

Oh my bad. I wonder if we shouldn't actually fail this request if this is not a network device.

For testing, just changing the library to force return that status on that call is enough.

That might be a good way to test it, sure. I don't have any experiences with C code and compilation (except for some Arduino stuff) but i will check it out later today.

This leads me to thinking in another direction. @Codeweep , have you tried to create the Dokan file system both as a network drive and a local drive? Any differences in this behaviour between the two mount modes?

I can't test at the moment but I think you might be correct. Issue is that the Dokan drive I provide is user session (DokanOptions.CurrentSession) related and the users are not allowed to edit their own registry in most cases. I had it set up originally as a network drive but got complaints because of the generic name and as far as I can tell there is no way of changing the drive name / icon without accessing the registry when using a network drive. But you're welcome to correct me if i am mistaken.

Thank you :)

[Codeweep]

Ok, to sum this up. I managed to modify the driver accordingly and was indeed able to make the app work as intended. However with one problem being taken care of others arose and it became clear that using our virtual drive wasn't pratical in this case. Now it's two other old apps running on VB and some ancient version of C++ ruining my day and we decided to use a different approach for this customer instead.

Despite that i want to thank you for your help @LTRData and @Liryna and I will definetly continue to use the virtual drive whenever plausible - just not in this case