What does HackerNews think of dokany?

User mode file system library for windows with FUSE Wrapper

Language: C

#25 in C
#26 in Windows
I lead a project that included shipping a filesystem driver and a virtual disk on Windows.

What I did to learn the lower-level APIs, and perform initial testing on the driver, was write a "mirror" drive. The user-mode code pointed to a folder on disk, the driver made a virtual disk drive, and all reads and writes in the virtual disk drive went to the mirror folder. All of our (cough) unit tests for virtual drive handling used the mirror drive. ("cough" because the tests fit into that happy area that truly is a unit test but drives people nuts about splitting hairs about the semantics between unit and integration tests.)

On Windows, you can implement something like that using Dokany, Dokan, or Winfsp. On linux, there's the Fuse API. On Mac, there's MacFUSE.

Even if you don't do a "mirror" drive, understanding the callbacks that libraries like Dokany, Dokan, Winfsp, and Fuse do helps you understand how IO happens in the driver. Many IO methods provided in popular languages provide abstractions above what the OS does. (For example, the Windows kernel has no concept of the "Stream" that's in your C# program. The "Stream"'s Position property is purely a construct within the .Net framework.)

https://dokan-dev.github.io/

https://github.com/dokan-dev/dokany

https://osxfuse.github.io/

Another place to start is the OS's documentation itself. For example, you can start with Window's CreateFileA function. This typically is what gets called "under the hood" in most programming languages when you open or create a file: https://learn.microsoft.com/en-us/windows/win32/api/fileapi/...

While FUSE doesn't work directly, there are userspace filesystem implementations for Windows. Dokany¹ even implements most of the FUSE API.

1. https://github.com/dokan-dev/dokany

There is a "sort-of" port (you were correct in saying a "similar thing for Windows"). It's Dokany: https://github.com/dokan-dev/dokany

Keybase.io and sshfs use it, currently. Personally, I love it. I'm sure you're right about performance limitations, but there are very good use cases for it, like Keybase Filesystem and sshfs, where any latency introduced by the driver subsystem is less likely to be felt due to the latency of working with files over the network.

Interestingly, a set of the insider previews of Windows broke Dokany so badly that launching the driver caused everything to hang (hard -- all but the mouse stopped responding to anything, even CTRL+ALT+DELETE). It's tricky stuff, apparently.

MIT might be a bit too strong of a switch for the author, but I think there is a better compromise than the AGPL. The AGPL has some worrying clauses in it that make it the actual legal nightmare that people used to paint the GPL with. I realize that may be the intention of the project author, but it does severely limit even other open source developers' willingness to touch the project with a ten foot pole.

I think a standard GPL license would be an improvement that would keep the intention and avoid some of the larger headaches of the Affero version.

Looks like Dokany is already LGPL/MIT-dual licensed though, so probably would just use that if I were building in this space: https://github.com/dokan-dev/dokany

It's worth mentioning than Dokany also provides a FUSE compatible API, see https://github.com/dokan-dev/dokany
Wow, didn't even know something like Dokany[0] was even possible on Windows, let alone being already available!

[0]: https://github.com/dokan-dev/dokany

Uh, this is exactly the type of thing that FUSE is good for. Doing this as a FUSE layer would be way way easier than for Windows (unless they used Dokany[1], and they probably didn't) or god knows what you have to do to get OS X to support user-space filesystems.

1. https://github.com/dokan-dev/dokany