Status of DokanY?

[Tony Gravagno]

Every couple years I look for a FUSE API for Windows, just to see if something new is available. It was troubling to see that the best one available for Windows, Dokan, was no longer under in active development, especially considering how widely FUSE is used for Linux.

But now there's DokanX and DokanY. I see a number of recent changes and resolutions of issues on DokanY. From what I've seen it appears to be the best chance that "we" have of getting some sort of FUSE for Windows.

My understanding is that DokanY is not yet ready for any kind of production use. That's fine. Obviously it's getting closer. As a developer I appreciate the nature of FOSS and everyone's personal contributions. I want to use the software and help where possible, but my skills are at a higher app level than down at the OS level. So I don't feel I can contribute much to the source but perhaps I can help on docs over time ... when I learn more about how it's working...

But what is the state of DokanY as perceived by the developers?

How comfortable are YOU with it?

What else needs to be done?

What are the known issues or things to avoid? (The Git Issue tracker doesn't seem to be the real knowledge base for all known issues)

Is there a list of supported and unsupported platforms or features?

Another aspect of this is that Windows keeps changing, and this kind of low-level development is often hit the hardest when a new OS comes out. So I'm hoping we can also look forward to assess the challenges that will be faced with Windows 10 and whatever else is going to be in production next year. If DokanY or any other FUSE interface is to gain support, it must be able to move quickly to the next upgrade. A commercial business can't hold back for too long on an OS update, pending insurmountable challenges facing developers of a low-level tool like this. We can't expect commercial use if there is a chance that the project is going to die with any given OS release. In other words, DokanY will get more support (more users and developer support) if there is some documentation that explains in general terms how it can be ported to each new version of Windows that comes out.

Thanks for any responses.

[Alejandro Exojo]

On 18 May 2015 at 19:07, Tony Gravagno <bacj8...@snkmail.com> wrote:
> Every couple years I look for a FUSE API for Windows, just to see if
> something new is available. It was troubling to see that the best one
> available for Windows, Dokan, was no longer under in active development,
> especially considering how widely FUSE is used for Linux.

Is it? Yes, I know there are lots of FUSE filesystems. But how many of
them are useful for "real people" (not geeks who compile the code for
themselves)? Does FUSE-based project exist that provide a
user-friendly product?

> But now there's DokanX and DokanY. I see a number of recent changes and
> resolutions of issues on DokanY. From what I've seen it appears to be the
> best chance that "we" have of getting some sort of FUSE for Windows.

My guess is that both DokanX and DokanY are used in production by some
people. I'm developing an application, and so far I'm using DokanY. I
have lots of little issues, but so far all seem to be my failure to
implement the file system application properly due to the lack of
documentation.

DokanX and DokanY are synchronized at the driver level, the stuff that
is built on C. But the DokanX opted for more radical changes to the
original Dokan sources, and people who need C APIs might be displeased
with that (not my case, I'm doing C++).

> My understanding is that DokanY is not yet ready for any kind of production
> use. That's fine. Obviously it's getting closer.

Why do you have that impression? I pretty much jumped into
implementing my own application, but an easy way to test is to run the
mirror application and see if it produces any errors for you.

> As a developer I appreciate
> the nature of FOSS and everyone's personal contributions. I want to use the
> software and help where possible, but my skills are at a higher app level
> than down at the OS level. So I don't feel I can contribute much to the
> source but perhaps I can help on docs over time ... when I learn more about
> how it's working...

That's my case as well. I don't feel like I can learn Windows driver
development just to help.

>
> But what is the state of DokanY as perceived by the developers?

Seems to work for me so far.

> How comfortable are YOU with it?

Badly, since I don't understand lots of things yet. I was thinking of
asking questions to the list, just in case somebody might answer. But
I've been postponing it due to the low expectations (very low traffic
in the list, etc.).

> What else needs to be done?

64bit mode probably. See the commits on DokanX attached to the issue tracker.

> What are the known issues or things to avoid? (The Git Issue tracker doesn't
> seem to be the real knowledge base for all known issues)

I can't think of any.

> Is there a list of supported and unsupported platforms or features?

I don't think you can install VS2013 on Vista, so I'd say you at least
need W7 for compiling the forks (X/Y). The driver and applications
might be compatible with older releases. The original Dokan compiles
on Vista and works.

> Another aspect of this is that Windows keeps changing, and this kind of
> low-level development is often hit the hardest when a new OS comes out. So
> I'm hoping we can also look forward to assess the challenges that will be
> faced with Windows 10 and whatever else is going to be in production next
> year. If DokanY or any other FUSE interface is to gain support, it must be
> able to move quickly to the next upgrade. A commercial business can't hold
> back for too long on an OS update, pending insurmountable challenges facing
> developers of a low-level tool like this. We can't expect commercial use if
> there is a chance that the project is going to die with any given OS
> release. In other words, DokanY will get more support (more users and
> developer support) if there is some documentation that explains in general
> terms how it can be ported to each new version of Windows that comes out.

I doubt windows has changed much in those levels. The file system
calls might will probably be supported "forever". Microsoft are
masters in keeping old stuff working. Windows RT might be a different
story, though, since the calls supported there are different.

[maxime....@gmail.com]

64-bit support is indeed something on the todo list for DokanY. In fact to answer your question "What else needs to be done?", I would answer with this link: https://github.com/Maxhy/dokany/labels/enhancement

I don't have any addition to it, the purpose of DokanY is not to radically change Dokan with new features but to keep it working correctly on latest Windows releases, free up bugs.

As Alejandra guessed in another thread, we (our company) are using it in production environment so as long our customer exists and upgrade his Windows versions, we will try to make DokanY working correctly on latest Windows installation. Windows 10 wasn't properly tested yet by ourselves, but I didn't noticed major changes in the kernel architecture that will impact Dokan and forks. Tests should confirm it.

[Tony Gravagno]

Sincere thanks to you both for your time here.

I'll follow-up below...

On Tuesday, May 19, 2015 at 10:04:39 AM UTC-7, maxime....@gmail.com wrote:

64-bit support is indeed something on the todo list for DokanY. In fact to answer your question "What else needs to be done?", I would answer with this link: https://github.com/Maxhy/dokany/labels/enhancement

I don't have any addition to it, the purpose of DokanY is not to radically change Dokan with new features but to keep it working correctly on latest Windows releases, free up bugs.

This part is exactly what I'm concerned about:
** to keep it working correctly on latest Windows releases, free up bugs. **
So I'm glad some folks are keeping up with it.

Is the issue with 64bit in low-level OS calls? Limits in addressable space?
Since most new systems these days are 64bit, my understanding here is that there aren't any 64bit systems running Dokan implementations, and that I can't even attempt to build or run it on my 64bit Win 8.1. Is that incorrect?

 

As Alejandra guessed in another thread, we (our company) are using it in production environment so as long our customer exists and upgrade his Windows versions, we will try to make DokanY working correctly on latest Windows installation.

But they aren't running over any 64bitOS?

 

Le lundi 18 mai 2015 19:47:20 UTC+2, Alejandro Exojo a écrit :

On 18 May 2015 at 19:07, Tony Gravagno <bacj8...@snkmail.com> wrote:
> Every couple years I look for a FUSE API for Windows, just to see if
> something new is available. It was troubling to see that the best one
> available for Windows, Dokan, was no longer under in active development,
> especially considering how widely FUSE is used for Linux.

Is it? Yes, I know there are lots of FUSE filesystems. But how many of
them are useful for "real people" (not geeks who compile the code for
themselves)? Does FUSE-based project exist that provide a
user-friendly product?

Well, no individual can confirm or deny the success of someone else's project without actually being involved, but of the hundreds of applications out there I would have to guess that some of them are successful. If we see hundreds of Linux-based implementations, and assume that it's still not widely used, we can't very well look at the handful of individuals using FUSE over Windows and conclude that it's successful enough for new development. See what I mean?



 

> But now there's DokanX and DokanY. I see a number of recent changes and
> resolutions of issues on DokanY. From what I've seen it appears to be the
> best chance that "we" have of getting some sort of FUSE for Windows.

My guess is that both DokanX and DokanY are used in production by some
people. I'm developing an application, and so far I'm using DokanY. I
have lots of little issues, but so far all seem to be my failure to
implement the file system application properly due to the lack of
documentation.

So at the moment I'm understanding one developer is creating an app, but with nothing in production yet, and another developer has it in production for a single client. Can you all see why I'm concerned?

> My understanding is that DokanY is not yet ready for any kind of production
> use. That's fine. Obviously it's getting closer.

Why do you have that impression?

A report of a BSOD from a recent build does not instill confidence, nor do some of the other small but significant issues reported just over the last couple months.

I completely understand that this is FOSS, generously supported and freely donated by a few dedicated people for the benefit of all. I have no lack of appreciation for the offering, nor a lack of understanding of the considerations for using and contributing to FOSS. But at the end of the day we all must ask ourselves if we can actually use this for production use, or can we help to get it ready, or should we do something else?

Without some confidence that there is more than one end-user using this for some limited application, I can't get myself to move forward with it any more than I did with Dokan. And even with the CBFS, based on Dokan and with ongoing development for years, we still see issues reported with CBFS. Can we in good conscience ask end-users to build their business solutions on applications we create with this technology?

No one has done this yet, but please don't respond with "if you don't like it then don't do it" - that puts the blame on me for asking questions that I would hope someone would be willing to answer. If the questions can't be answered honestly and completely then each person needs to ask themselves why they are moving forward, or what else we can all do to help stabilize this great code base.



 

I pretty much jumped into
implementing my own application, but an easy way to test is to run the
mirror application and see if it produces any errors for you.

If I run the test app on my development system and it works, I still don't have information/confidence I need to justify offering this to end-users who run on a variety of platforms. I need to be able to tell people that this does or does not work in specific environments so that we know where we can install it. Otherwise we'll get hit with "you said this would work" and support calls to fix something that people here will say "oh yeah, it doesn't work there...". With all of the information on the table ahead of time we can all make good decisions.


 

>
> But what is the state of DokanY as perceived by the developers?

Seems to work for me so far.

> How comfortable are YOU with it?

Badly, since I don't understand lots of things yet. I was thinking of
asking questions to the list, just in case somebody might answer. But
I've been postponing it due to the low expectations (very low traffic
in the list, etc.).

If I see more traffic here I'd certainly have more confidence in using the code myself. I think everyone is like that. No one likes coming to a forum where the top question is "is this thing dead?". If we can get Q&A here then the information can be translated into a wiki, which I'd be happy to help maintain and to add info as I learn more.

 

> Is there a list of supported and unsupported platforms or features?

I don't think you can install VS2013 on Vista, so I'd say you at least
need W7 for compiling the forks (X/Y). The driver and applications
might be compatible with older releases. The original Dokan compiles
on Vista and works.

I was asking more about target/end-user platforms than developer systems. I run on Win8.1/64 with VS2013 Community (used to have Ultimate but no need anymore). I'm guessing I would need to install and test a virtual machine with Win2012 server, Win8.0/32 and anything else that's recent. I wouldn't even offer a solution for Vista or XP.



 

> Another aspect of this is that Windows keeps changing, and this kind of

> low-level development is often hit the hardest when a new OS comes out....

I doubt windows has changed much in those levels. The file system
calls might will probably be supported "forever". Microsoft are
masters in keeping old stuff working. Windows RT might be a different
story, though, since the calls supported there are different.

That's interesting, as I figured they can't claim to have improved the file system if they don't change it. :)  But I'll accept that the low-level API has not changed. My only concern would be for Win10, which is the only platform coming in the foreseeable future. I'm sure you see the situation ... as soon as people start buying new systems with Win10, they'll want to use the applications they've come to appreciate on older systems. And like we're looking forward to 64bit support here, our clients will start asking for support for their new systems too. That's the way it all works. I'm just curious what the current thinking in that area is.
 

Thanks again, and please remember that this is all intended to be constructive and hopefully to lead me to a lot of hours with this software and with you folks.

[maxime....@gmail.com]

64-bit support issue is about userlib, the kernel driver is already provided in 64-bit. Changing the build option to create 64-bit dlls is simple but appropriate test need to be done to ensure everything is working correctly. It will.
Your other points is about confidence.

You will never get a statement "we ensure this is working perfectly" but I can tell you that we created DokanY to be close to it. Indeed we only have one customer, but this one is a distributor who installed dozens of end users, on Windows Vista, 7, 8, 8.1, 32-bit and 64-bit (Windows XP support was officially dropped for us). The only thing you can be sure is that if our customer (= one of his end user) encounter a bug related to DokanY, we will do what it takes to fix it. Our decision was close to your reflexion :
 - We *needed* a FUSE-like architecture on Windows
 - Only three valid choices in our opinion: Dokan and forks, a commercial product named Eldos Callback File System, or another commercial one named Pismo File Mount. I can see both commercial products are making their business trying to migrate user from Dokan to their file system driver. I'm more confident with open source when talking about drivers it's why we ended up using Dokan, but maybe I'm wrong here
 - We encountered BSOD on Dokan that needed to be fixed
 - We needed signed drivers
 - We didn't like how DokanX fork was going and its git history make it hard to see changes with original Dokan project

So we created DokanY fork maintained by our company development team to match our expectation. Keeping it open source and providing our signed driver because we believe it will be useful for other people/company.
I will be completely honest, we decided to focus on bug fix because it could affect our end-users. We decided to not develop new features (Dokan is missing few FS callbacks implementation for instance) because we don't need it and our company is too small to support this kind of development cost without ROI. As a company we will only focus on bug fix, as individuals we believe a FUSE-like project on Windows must be open source and a strong community is needed for that.

[Alejandro Exojo]

On 21 May 2015 at 02:20, Tony Gravagno <bacj8...@snkmail.com> wrote:
> This part is exactly what I'm concerned about:
> ** to keep it working correctly on latest Windows releases, free up bugs. **
> So I'm glad some folks are keeping up with it.
>
> Is the issue with 64bit in low-level OS calls? Limits in addressable space?
> Since most new systems these days are 64bit, my understanding here is that
> there aren't any 64bit systems running Dokan implementations, and that I
> can't even attempt to build or run it on my 64bit Win 8.1. Is that
> incorrect?

Yes, incorrect. I'm running in Windows 64bit, but the app is compiled
in 32 bit mode. That was already a limitation of other libraries I'm
using, and MinGW AFAIK doesn't have a stable 64bit toolchain. No big
deal for many people.

See the explanations and the little changes needed in the linked issues:
https://github.com/Maxhy/dokany/issues/5

> Well, no individual can confirm or deny the success of someone else's
> project without actually being involved, but of the hundreds of applications
> out there I would have to guess that some of them are successful. If we see
> hundreds of Linux-based implementations, and assume that it's still not
> widely used, we can't very well look at the handful of individuals using
> FUSE over Windows and conclude that it's successful enough for new
> development. See what I mean?

No, I don't see which applications you mean. I don't know of any
application in Linux that works in a similar way to what I'm doing
right now with Dokan. The only FUSE filesystem I can think of that I
would like to have as big part of my desktop workflow is MTPFS. The
others, like YouTubeFS, SSHFS and the like, are cool toys for geeks.
Very useful, and some probably used by many people for getting stuff
done, but I don't see which of them are supposed to be used by plain
end users. That's what I mean.

> So at the moment I'm understanding one developer is creating an app, but
> with nothing in production yet, and another developer has it in production
> for a single client. Can you all see why I'm concerned?

That's not what I said at all.

> Without some confidence that there is more than one end-user using this for
> some limited application, I can't get myself to move forward with it any
> more than I did with Dokan.

Again, making stuff up.

> And even with the CBFS, based on Dokan

I don't know where is this coming from. I haven't downloaded CBFS
because of the licensing, but because of the licensing
incompatibilities, and because the API exposed seems very different, I
severely doubt CBFS is based on Dokan.

> and with
> ongoing development for years, we still see issues reported with CBFS. Can
> we in good conscience ask end-users to build their business solutions on
> applications we create with this technology?

I fear that you have very little idea of how actual software is. See:

https://bugzilla.kernel.org/

And be scared by the amount of bugs reported each day.

> No one has done this yet, but please don't respond with "if you don't like
> it then don't do it" - that puts the blame on me for asking questions that I
> would hope someone would be willing to answer. If the questions can't be
> answered honestly and completely then each person needs to ask themselves
> why they are moving forward, or what else we can all do to help stabilize
> this great code base.

You should ask yourself why you have such a negative opinion of
something you don't seem to have tried. The DokanY installers are some
clicks away. After that you have all pieces deployed, and an
application file system installed (mirror.exe).

> If I run the test app on my development system and it works, I still don't
> have information/confidence I need to justify offering this to end-users who
> run on a variety of platforms. I need to be able to tell people that this
> does or does not work in specific environments so that we know where we can
> install it. Otherwise we'll get hit with "you said this would work" and
> support calls to fix something that people here will say "oh yeah, it
> doesn't work there...". With all of the information on the table ahead of
> time we can all make good decisions.

You could know all of this if you would have read the issue trackers.
Instead you wrote a lengthy email with lots of misinformation that
took me half an hour to reply.

> That's interesting, as I figured they can't claim to have improved the file
> system if they don't change it. :) But I'll accept that the low-level API
> has not changed. My only concern would be for Win10, which is the only
> platform coming in the foreseeable future. I'm sure you see the situation
> ... as soon as people start buying new systems with Win10, they'll want to
> use the applications they've come to appreciate on older systems. And like
> we're looking forward to 64bit support here, our clients will start asking
> for support for their new systems too. That's the way it all works. I'm just
> curious what the current thinking in that area is.

From the little I know of Windows, this is not going to be an issue. A
restricted subset of operations, like on Windows RT, that would be a
problem. Windows 10? I don't see what they could change that might
break Dokan.

> Thanks again, and please remember that this is all intended to be
> constructive and hopefully to lead me to a lot of hours with this software
> and with you folks.

Good luck and welcome on board.

[Tony Gravagno]

That's a great response, and very encouraging. Thank you very much.

[Federico Bianchi]

As a side note, there are some situations where a local pseudo-WebDAV server may still be a safer option (at least, till a Dokan fork coalesces or Microsoft folks add FUSE-like facilities to stock Windows): you can find the relevant code from Safe App folks on GitHub. CarotDAV is also working in a similar way.

Best regards

Federico Bianchi

2015-05-21 17:26 GMT+02:00 Tony Gravagno <bacj8...@snkmail.com>:

That's a great response, and very encouraging. Thank you very much.

--
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]

Responses inline

On Thursday, May 21, 2015 at 12:19:08 AM UTC-7, Alejandro Exojo wrote:

On 21 May 2015 at 02:20, Tony Gravagno <bacj8...@snkmail.com> wrote:

>... my understanding here is that

> there aren't any 64bit systems running Dokan implementations, and that I
> can't even attempt to build or run it on my 64bit Win 8.1. Is that
> incorrect?

Yes, incorrect. I'm running in Windows 64bit, but the app is compiled
in 32 bit mode. 

Thanks for the clarification - so we Can run in 32bit mode over 64bit.

 

... I don't know of any

application in Linux that works in a similar way to what I'm doing
right now with Dokan. The only FUSE filesystem I can think of that I
would like to have as big part of my desktop workflow is MTPFS. The
others, like YouTubeFS, SSHFS and the like, are cool toys for geeks.
Very useful, and some probably used by many people for getting stuff
done, but I don't see which of them are supposed to be used by plain
end users. That's what I mean.

http://sourceforge.net/p/fuse/wiki/FileSystems/
Feel free to believe that there are no end-user applications in there. I won't argue.
 

> So at the moment I'm understanding one developer is creating an app, but
> with nothing in production yet, and another developer has it in production
> for a single client. Can you all see why I'm concerned?

That's not what I said at all.

OK, well, you said that you were developing but not that you had a published application which is being used by end-users. I accept a correction.
 

> Without some confidence that there is more than one end-user using this for
> some limited application, I can't get myself to move forward with it any
> more than I did with Dokan.

Again, making stuff up.

You're getting personal and defensive. I'm just echoing what I've read here. If I'm mistaken, tell me so and correct me, but don't just assert that I'm wrong or making things up and move on. We don't learn anything from that.

So what Is your application, and do you have end-users using it? Please do share if you can.


 

> And even with the CBFS, based on Dokan

I don't know where is this coming from. I haven't downloaded CBFS
because of the licensing, but because of the licensing
incompatibilities, and because the API exposed seems very different, I
severely doubt CBFS is based on Dokan.

I wasn't talking about you. With all of the comparisons of Dokan to CBFS that I've seen, and the similarity in the API, I thought CBFS was a derivative of Dokan. This seems to be incorrect.

https://www.eldos.com/cbfs/no-dokan.php
https://www.eldos.com/cbfs/dokan-to-cbfs.php

 

> and with
> ongoing development for years, we still see issues reported with CBFS. Can
> we in good conscience ask end-users to build their business solutions on
> applications we create with this technology?

I fear that you have very little idea of how actual software is. See:

https://bugzilla.kernel.org/

And be scared by the amount of bugs reported each day.

I use that reference myself when people brag about how flawless open source is compared to commercial software.
I've only been writing code for about 35 years so I guess I have a lot to learn.
But with your empty rebuttals to my points, I have yet to see evidence that this specific project has a level of stability that I personally would consider adequate to support a deep investment.

 

>... that puts the blame on me for asking questions that I

> would hope someone would be willing to answer. If the questions can't be
> answered honestly and completely then each person needs to ask themselves
> why they are moving forward, or what else we can all do to help stabilize
> this great code base.

You should ask yourself why you have such a negative opinion of
something you don't seem to have tried.

You're doing exactly what I've asked people not to do. I don't have an opinion either way, I'm asking open questions.
What concerns me is that the more I read about Dokan the more it seems people have tried it and moved away rather than adopting it.



 

> If I run the test app on my development system and it works, I still don't
> have information/confidence I need to justify offering this to end-users who
> run on a variety of platforms. I need to be able to tell people that this
> does or does not work in specific environments so that we know where we can
> install it. Otherwise we'll get hit with "you said this would work" and
> support calls to fix something that people here will say "oh yeah, it
> doesn't work there...". With all of the information on the table ahead of
> time we can all make good decisions.

You could know all of this if you would have read the issue trackers.
Instead you wrote a lengthy email with lots of misinformation that
took me half an hour to reply.

No, the issue tracker has 6 open items and 7 closed items. There's not enough information there on which to base an opinion.


 

> Thanks again, and please remember that this is all intended to be
> constructive and hopefully to lead me to a lot of hours with this software
> and with you folks.

Good luck and welcome on board.

I appreciate the welcome and your time here, but I'm not on board yet. My opinions aren't helped with your choice of personal jabs over solid facts or technical responses.

That actually doesn't influence me much. I won't base my opinion on one person any more than I will base it on one app. The problem I have here is that so far it seems like there are only two apps represented by this code base. I hope anyone can agree that this by itself is "scary" at the least.

Thanks again.

[Alejandro Exojo]

On 21 May 2015 at 18:53, Tony Gravagno <bacj8...@snkmail.com> wrote:
>> > Without some confidence that there is more than one end-user using this
>> > for
>> > some limited application, I can't get myself to move forward with it any
>> > more than I did with Dokan.
>>
>> Again, making stuff up.
>
> You're getting personal and defensive. I'm just echoing what I've read here.
> If I'm mistaken, tell me so and correct me, but don't just assert that I'm
> wrong or making things up and move on. We don't learn anything from that.
>
> So what Is your application, and do you have end-users using it? Please do
> share if you can.

I did not get personal, but I did get defensive because I felt a
little bit attacked by your statements. Let's try to start over. No
hard feelings, just trying to be understood.

I can't share details of what I am doing because I don't necessarily
can. But I don't think it's fair to say "one end-user using this for
some limited application". First, why the limited? I don't know why
what Maxime explained has to be qualified as limited. Second, if you
look at the development of Dokan, the original author kept developing
it for several years (and made releases). DokanX did not had releases,
but the author did commits spread through several years. DokanY has
releases too. Some people here and there have been reporting issues or
contributing fixes. I think is more fair to assume that some people
has to be using Dokan.

>> > and with
>> > ongoing development for years, we still see issues reported with CBFS.

(...)

> I use that reference myself when people brag about how flawless open source
> is compared to commercial software.
> I've only been writing code for about 35 years so I guess I have a lot to
> learn.
> But with your empty rebuttals to my points, I have yet to see evidence that
> this specific project has a level of stability that I personally would
> consider adequate to support a deep investment.

"with ongoing development for years, we still see issues reported"

That's the stuff I don't get, and why I gave a quick short response.
Every software gets issues all the time, even if it's been heavily
developed for stability.

> You're doing exactly what I've asked people not to do. I don't have an
> opinion either way, I'm asking open questions.
> What concerns me is that the more I read about Dokan the more it seems
> people have tried it and moved away rather than adopting it.

You say you don't have an opinion either way, but you (literally, or
implied) that it has almost no users, the the only application
deployed is limited, that people still keep reporting issues... And
then after saying that you have no opinion either way you say that you
think people have "moved away rather than adopting it". I don't think
that's fair.

>> You could know all of this if you would have read the issue trackers.
>> Instead you wrote a lengthy email with lots of misinformation that
>> took me half an hour to reply.
>
> No, the issue tracker has 6 open items and 7 closed items. There's not
> enough information there on which to base an opinion.

I was writing about the supported platforms. The readme, and the issue
#5 (https://github.com/dokan-dev/dokany/issues/5) mention what's there
and what's not about the 64bit support for example. More information
on supported versions is in the readme for example. The original Dokan
readme says: "Dokan Library works on Windowx XP,2003,Vista,2008,7 x86
and Windows 2003,Vista,2008,7 x64." DokanY introduces minimal changes
besides the build system.

> I appreciate the welcome and your time here, but I'm not on board yet. My
> opinions aren't helped with your choice of personal jabs over solid facts or
> technical responses.

I honestly think that you weren't very accurate in your choice of
words or your statements. And certainly I don't see where I have been
personal. I've been pointing stuff out and criticising what I think
are hasty, unfair conclusions.

[Tony Gravagno]

You've provided a very fair and carefully considered response - thank you.
I really can't disagree with anything you've said here.
When I used the term "limited", I was referring to the statement by Maxime that one client had a single application, which was being used by end-users of that entity. I was also referring to Maxime's statement that they only address what they need. This is completely understandable and it fits in the context of FOSS and basic development. But for "our" (anyone looking for a WinFUSE solution) purposes, is that stable but "focused" usage of a subset of what this software might be capable of enough to help the rest of us base our decisions? I don't think so. I'm not trying to be negative, though you do point out that my notes of concern do bend in that direction. But I have very little positive information to balance out the very sparse overall information that we have about this. I mean, if I say I want to consider .NET versus Java for development, we can easily consult a wealth of information on either. If I say I'm considering COBOL.NET, someone might ask "why? who's using it? does that even exist anymore?". This is the sort of disparity we have when considering Dokan to CBFS or Ease or whatever else might be on the table. There's just not enough good Or bad info out there to be compelling. I'm hoping we can break through this over time, as I get more familiar with DokanY and other alternatives to judge for myself where it fits or not.

Thanks again.

[Tony Gravagno]

I wrote:

> And even with the CBFS, based on Dokan

I don't know where is this coming from. I haven't downloaded CBFS
because of the licensing, but because of the licensing
incompatibilities, and because the API exposed seems very different, I
severely doubt CBFS is based on Dokan.

I wasn't talking about you. With all of the comparisons of Dokan to CBFS that I've seen, and the similarity in the API, I thought CBFS was a derivative of Dokan. This seems to be incorrect.

https://www.eldos.com/cbfs/no-dokan.php
https://www.eldos.com/cbfs/dokan-to-cbfs.php
 

Now I see where I got that idea that CBFS is based on Dokan (which is not correct).
It's from this very forum. LOL
https://groups.google.com/d/msg/dokan/wRa9xw4BVv8/c05IydsEpzEJ

Oh well, we all know the interwebs are full of misinformation...

[Sven Harazim]

how difficult is it, to support network mountpoints, that i can access the filesystem per UNC path from remote computers?