FOSS Windows Drivers and Dokan?

[Tony Gravagno]

Does anyone have thoughts on the recent opening of related Windows source?
http://blogs.msdn.com/b/windows_hardware_and_driver_developer_blog/archive/2015/03/18/windows-driver-frameworks-source-on-github.aspx

They provide source to drivers and filters. I'm wondering if it would be worthwhile to start looking into a managed wrapper for that code rather than continuing with this one which has a number of known limitations.

[Maxime Chamley]

Thanks for sharing, I missed that!

But I'm not sure what it would change. A File System Driver remains a File System Driver, what else would you like to wrap ?

--
You received this message because you are subscribed to the Google Groups "Dokan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dokan+un...@googlegroups.com.
To post to this group, send email to do...@googlegroups.com.
Visit this group at http://groups.google.com/group/dokan.
For more options, visit https://groups.google.com/d/optout.

[Tony Gravagno]

Honestly I'm still trying to figure out the angles myself.

Rather than low-level implementation of a file system driver, developers might want to consider a Filter Driver or MiniFilter Driver which invokes user space apps. (This might be exactly how Dokan works, no clue yet.) A filter driver would send a message to managed code for processing, and that app code then returns messages or data, which in turn the OS then returns to requesting apps. Coding at this layer might make Dokan-like functionality available to a broader base of developers, without the concerns for unimplemented features or stability.

Docs on these concepts:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff548143%28v=vs.85%29.aspx

The Github page provides sample source code for implementation of mini filters.

Having done more research lately, I'm still trying to figure out what the various strategies are, from filters with the inverted callback model, to reparse/mount points, or whatever it is that Dokan does. (Any docs on that or do we just need to read the code?)

As someone who is not competent with C or C++, even managed yet, for now I need to avoid anything that requires C coding, and I need to search for C# solutions that use DllImport or similar to call down for functionality.

Thanks.

[maxime....@gmail.com]

Filter driver and MiniFilter driver doesn't have the same purpose than a File System driver.

I developed both years ago and the coming of MiniFilter driver with Windows XP SP3 was really a big good change from Microsoft ; if your purpose is just to add encryption or access control layers that's fine... but this is not a file system driver.

Dokan *is* a file system driver bringing core features to user mode and few commercial alternatives are also file system drivers. From what I know there is no other technical way to do it.

[Tony Gravagno]

Today I'm reading in-depth technical details on these topics, and for the first time in many years all of it is finally making sense. Right now I'm focusing on minifilters but I understand what you're saying about Dokan being a lower-level file system. I think for applications I'm considering now, I'm trying to work out whether a minifilter is adequate or whether I need to use a file system. For example:

A request is made from a common user-mode app to read a file from disk - the app doesn't know or care if this is NTFS or a custom FS.

A minifilter for the read can process and satisfy the request, and (I believe) tell the file system to ignore it.

A file system accepts all requests directly and must process all CRUD operations.

Is that understanding of the flow incorrect?

I guess it would be better to use a file system to handle all CRUD related to a specific application.

So when people say Dokan is missing functionality, are they talking about some of the FSCTL codes?

Thanks

[maxime....@gmail.com]

The difference requires more explanation and Microsoft did a great job on the explanation since latest WDK releases and even better since they started talking about WDF (DDK was such a pain...).

If you want to know the difference and similarity between File System Filter Driver (and MiniFilter driver) and Device Driver, see https://msdn.microsoft.com/en-us/library/windows/hardware/ff548202%28v=vs.85%29.aspx

In a general overview from what I saw, only a few projects using Dokan today could have done it with a MiniFilter driver instead of a Device driver.

I don't know the whispers about Dokan missing functionalities and maybe it would be good to summarize it officially in a wiki page (https://github.com/dokan-dev/dokany/wiki/Unsupported). There is some missing features that I'm aware of and FSCTL is one of them (no real FSCTL support in Dokan, all commands return success without any processing).

[Tony Gravagno]

I've been monitoring your Git updates and I seriously appreciate that you've translated comments here into Wiki notes and other updates. Now I'm feeling compelled to contribute. :)

I've seen those MS docs and am still making sense of them. My thinking right now is that I believe someone implementing a Filter Driver would need to do that kernel-level development, plus the mini drivers, and then do their user mode development on top of that. That's a lot of work. For those of us who don't write C or aren't familiar with kernel-mode development that puts this functionality out of reach. So I agree that file system options do seem to be best for most purposes outside of the two common examples of encryption and malware detection.

About the "the whispers about Dokan missing functionalities", it's pretty easy to Google for "dokan cbfs" to find a number of people who tried to use Dokan some years ago, they found it had problems, and they decided to switch to a commercial offering. Their web pages are aggressively against Dokan, which they obviously perceive as the leading competition:
https://www.eldos.com/cbfs/no-dokan.php
Too many people look at old Dokan data and don't know about DokanX/Y or current usage/efforts. This comes back to my statements that there just isn't enough current data, for or against Dokan, which helps someone to make a decision today.

I had a chuckle a their list of things that are missing from Dokan. This isn't missing functionality but honest value-add which CBFS has built over their core offering. There's nothing wrong with differentiation but they do pitch it like Dokan is deficient in not having their features - even though the features aren't "needed" for basic functionality. Still, they do provide a list of options which would be nice for a Dokan roadmap ... and a roadmap is exactly one of the features which Dokan is missing and which they consider a part of their value-add.
https://www.eldos.com/cbfs/dokan-to-cbfs.php
Note that they incorrectly state this feature is not supported by Dokan, where it is: "Folder on existing NTFS drive instead of drive letter as a parameter to AddMountingPoint() method"


Enough for now.