This is a minor version.

Glad to be back! 😉
It has been more than a year since the last release which was due to the expiration of our Extended Validation Certificate used for signing the driver and releases.
Thanks to the 💰 contribution from Google and the endless 💪 support from Leosac (Check their great stuff!), we were able to acquire a new certificate valid for the next 3 years 🎉 🎈

Major changes:

• Microsoft has changed the rules of which type of drivers (primitive) can be signed through their platform. Therefore we had to adapt how dokan is installed. Please let us know if you have any install / uninstall issue.
• New library unmount API introduced by @LTRData.
• Few (rare) BSOD fixed.

Please see changelog for the other changes and more details.

Thanks to all the contributors as always !!! @LTRData, @ylgybbz, @uhonermann, @hkf7703, @FaerieLee ....
Hope you will all enjoy our first and last 2023 release, see you in 2024!

This is a patch version.

If you are already using 2.0.5, there is no reason to update unless you are impacted by the delete notification during FileDispositionInformation #1111.

Please see changelog for more details.
And again here is how to migrate an existing > 1.1.0 filesystem to 2.0.0 and note the rollback of the FindFilesWithPattern v1 behavior from 2.0.5.

Thanks to all the contributors as always !!! @onexzero, @KoltesDigital

This is a patch version.

It includes a fix for Case Sensitive listing, UNCName not removed on unexpected casing, the possibility to override the read max size on FUSE and the rollback of the FindFilesWithPattern v1 behavior from 2.0.5.

Please see changelog for more details.
And again here is how to migrate an existing > 1.1.0 filesystem to 2.0.0 and note the rollback of the FindFilesWithPattern v1 behavior from 2.0.5.

Thanks to all the contributors as always !!! @KoltesDigital

This is a patch version.

It focuses on clarifying the usage of FindFiles and FindFilesWithPattern with their changes in v2, removing UNCName possible prefix on CreateFile and few Kernel fixes.

Please see changelog for more details.
And again here is how to migrate an existing > 1.1.0 filesystem to 2.0.0.

Thanks to all the contributors as always !!! @ATRiiX @robert-j

This is a patch version.

No new binaries were built for this version. They have only been repacked in a new installer that fixes the remaining conflict with the v1 one.

Please see changelog for more details.
And again here is how to migrate an existing > 1.1.0 filesystem to 2.0.0.

Thanks to all the contributors as always !!!

This is a patch version.

The version focus on improving the read & write performances that in some cases were worse than v1. 2.0.3.1000 is now faster on all those scenarios by 10 to 42%. Otherwise few stability and installer fixes were added.

Please see changelog for more details.
And again here is how to migrate an existing > 1.1.0 filesystem to 2.0.0.

Thanks to all the contributors as always !!!

This is a patch version.

It includes different library and kernel pulling thread fixes, a library crash and proper DokanResetTimeout support.

Please see changelog for more details.
And again here is how to migrate an existing > 1.1.0 filesystem to 2.0.0.

Thanks to all the contributors as always (@nikola-sh) !!!

This is a patch version.

Even if this is only a patch version that polish the v2 first release and finally makes it possible to have Dokan v1 and v2 installed side to side... the DokanFCB storage was switched from a simple list O(n) to an Adelson-Velsky/Landis (AVL) table log(n).
It will not make much difference when a few files are open but if you had 16k files opened, the kernel would only make ~4 string compared instead of 16k which is 🚀 during CreateFile.

Benchmark that compare this version against 1.5.1.1000 in multiple scenarios here

Please see changelog for more details.
And again here is how to migrate an existing > 1.1.0 filesystem to 2.0.0.

Thanks to all the contributors as always (@ATRiiX) !!!

See 2.0.1.2000

This is a major version.

We have finally moved to version 2!

Introduce Thread & Memory pool to process and pull events by batch.

This is highly based on #307 but without the async logic. The reason is to avoid using the kernel NotificationLoop that was dispatching requests to workers (userland thread) sequentially since wake up workers have a high cost of thread context switch.
The previous logic is nice when you want workers to be async (like #307) but as we have threads (and now even a thread poll) dedicated to pull and process events, there is no issue to make them synchronously wait in kernel for new events and directly take them from the pending request list.

The library will start with a single main thread that pulls events by batch and dispatches them to the thread pool but keeps the last one to be executed (or the only one) to be executed on the same thread. Each thread waken will do the same and pull new events at the same time. If none is returned, the thread goes back to sleep and otherwise does the same as the main thread (dispatch and process...etc).
Only the main thread waits indefinitely for new events while others wait 100ms in the kernel before returning back to userland.Batching events, thread and memory pool offers a great flexibility of resources especially on heavy load. Thousands of lines of code were changed in the library (thanks again to @Corillian contribution of full rewrite) but the public API hasn't changed much.

After running multiple benchmarks against memfs, sequential requests are about +10-35% faster but in the real world with the thread pool the perf are way above. @Corillian full rewrite of FindFiles actually improved an astonishing +100-250%...crazy 😱

Much more was added, please see changelog
See here how to migrate an existing > 1.1.0 filesystem to 2.0.0.

Thanks to all the contributors as always (@ATRiiX) !!! and big thanks again to @Corillian who has waited years to get his work merged!