Is this project still managed?

[infeo]

Hey, I'm wondering if this dokany-adapter for Java is still developed, because the current library is not usable with the newest dokany adapter (see #13 ) and the issue with the broken links (#12 ) is still unanswerd after more than 10 months...

I'm asking because at my work we use this adapter for an open source project (see https://github.com/cryptomator/cryptomator) and now want to give back the changes to the community :)

You can have a look at the "new" dokan-java-wrapper here: https://github.com/infeo/dokan-java

And if you are looking for a new maintainer, currently i got some spare time left... (-;

[Liryna]

Hi @infeo ,

Thank you for your proposition. I have always been looking for a maintainer for the dokan java wrapper. In August, there is @soywiz that joined us and proposed to be the maintainer. I currently do not know if he is still active or not (probably). I will let him answer here and otherwise we will look what we can do 👍

Can you say a couple of words that can describe the difference between the current dokan-java and you new one ?

[infeo]

Of course, in the following is a (uncomplete) list of changes and the reasons behind them:

• Removal of Lombock: Lombock is a nice to tool to reduce boilerplate code, but is also a problem to dive into a project (not used to it/ide does not support it/ etc). Addtionally without it, things must be set more explicit, which may be in case of filesystems not so wrong
• Java 11: Updated the project to the latest java LTS release
• Fixed, updated and created a lot of documentation (broken/wrong links, missing parameters, etc)
• added support for (selfrelative) security descriptors. Its far from complete, but a beginning
• removed the dokanyOperationsProxy class: it was an mixture of "i just delegate something to the developer" and "let me handle this" . Now the developer must think about every Dokany API method if he implements it or not and how
• introduced the following chain of inheritance: Mountable <- DokanyFileSystem <- AbstractDokanyFileSystem <- DokanyFileSystemStub <- [YOUR FILESYSTEM]
• Mountable: Interface which provides the mount & unmount methods
• DokanyFileSystem: Interface which provides in a 1:1 correspondence the dokany file operations
• AbstractDokanyFileSystem: Abstract class. Implements the mount & unmount methods and sets during its creation the dokanyOperationsStruct (see more below). The developer can decide if his filesystem meddle with userspace or kernelspace flags
• DokanyFileSystemStub: This class implements every method of the DokanyFileSystem. As long as a method is not overwritten in a subclass, the corresponding field is set to null in the OperationsStruct at initialization.
• Decision between a more object-oriented and therefore typesafe approach or performance: When you develop your filesystem, you can use Enumerations to stay typesafe to handle some integer flags or use directly the integer masks (e.g. CreateDisposition is the Enumeration and CreateDispositions is the file with the real constants)

[Rondom]

Good work!

[Liryna]

Hi @infeo ,

Sorry to answer only now. Your changelog is like a sweet music to my ears 😍 I have sent an invitation to join the Dokan Java team. It should give you the right to do all the changes you will need here 👍

Do not hesitate if you need anything !

[infeo]

I guess this is settled now. 😄