This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ITP] FUSE 2.8


Take a step back, Bill :)

Here I am only concerned about a non-official fuse project "fuse"
willing to use the fuse name and that would fool cygwin users.

Since I never tested your solution, I only reuse your own sentence
from dokan Google groups/reddit
but if you continue to say that I spread rumors, I will be happy to
show every of your own words.

Dokan is also always in trending projects for the current day/week
when a release is made on reddit.
You will learn the truth that there is a different in the number of
"Stars" and the number of people/bot who really use the project.
For information on your last release: curl -u "username"
https://api.github.com/repos/billziss-gh/winfsp/releases
=> winfsp-0.14.16197.msi - "download_count": 24
>You do not know how many people use WinFsp ..
>Furthermore being the number 1 trending project on GitHub (for the C language) certainly shows some favorable feedback.
You seem to also don't know how many people use it.

>I note that you use my own file system test suites to test your file systems
Yes, we use some of your file system test suites since you propose to
use it for testing Dokan at first, should we not ?
We also use tools that we created and others from Microsoft.
I don't understand your point here :(

>takes file system semantic correctness far more seriously than Dokany
Yes Dokan come from far, we changed a lot and we keep going on this way
Please be my guess, here is the result of 2 years of works:
https://github.com/dokan-dev/dokany/graphs/contributors
http://isitmaintained.com/project/dokan-dev/dokany

>could enumerate all of Dokany’s failings, but I will spare you the embarrassment.
There is no embarrassment Bill ! We already told you that we would be
please to have a feedback from you on google groupe.
Having issues and fixing it is the only goal here. It is even why we
revived the project ! Fixing and improving it! Be also my guess for
it.
As an example, you added test suits (keep the good work !), we use
them and we fixed issues if there were.

Dokan come from far since it was an old project and there is nobody
that can say we didn't do our best and that we didn't take care of ALL
issues.
It is also a project that showed his strange during the age !

Normally I wouldn't answer to such message as you did but I seens you
are using the same arguments on every conversation comparing
WinFSP/Dokan, I have feel that I need to make things clear.
If you wanna continue this conversation, please do not use this cygwin
thread and lets continue how winfsp-fuse and dokan-fuse can be added
to cygwin packages we a correct dependancy.

Liryna

2016-07-22 19:55 GMT+02:00 Bill Zissimopoulos <billziss@navimatics.com>:
> On 7/22/16, 4:59 AM, Adrien JUND wrote:
>
>
>>The package should be renamed winfsp-fuse for give ability of cygwin
>>users to choose which solution they would like to use. Like
>>dokan-fuse, cbfs-fuse and other projects that offer the same
>>service...
>
> I am not opposed to renaming the package if that’s what the Cygwin
> community wants.
>
> However I note that this may create the following problem. Packages that
> depend on FUSE will need to have that dependency satisfied by a number of
> different *-fuse packages. Perhaps the dependency system in Cygwin is
> flexible enough to support this (I don’t know).
>
> For example I am planning to follow up this submission with SSHFS and
> FUSEPY submissions. I would like to make these packages depend on a FUSE
> package, so that we do not end up with a winfsp-sshfs package, a
> dokan-sshfs package, etc. Even more importantly I would like SSHFS and
> FUSEPY to build/run out of the box without having to add special logic for
> winfsp-fuse vs dokan-fuse, etc.
>
>
>>The official fuse window integration is an official request made by
>>devs on WPDEV. This request is well placed on the top so it is
>>probably only a question of time before windows do it in the same time
>>as the Linux subsystem integration.
>>https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-u
>>buntu-on-windo/suggestions/13522845-add-fuse-filesystem-in-userspace-suppo
>>rt-in-wsl
>
> I am sorry, but having worked for Microsoft this is definitely wishful
> thinking. If anything Microsoft would likely do it themselves. Heck I
> might just rejoin them and do it for them ;)
>
>>I also would like to point out that WinFSP has absolutely no feedback
>>of any kind by users and has not been tested on all windows versions.
>>I think Kernel drivers should at least have some feedback and known as
>>used in production before choosing to be distributed as cygwin
>>package.
>>Unstable kernel drivers can create severity damage in case of BSOD
>>like windows or user files corruption.
>>
>>These analyses are probably severe but for the good of cygwin users,
>>integrate kernel driver dependence should be well thought before
>>making the step.
>
> Rubbish!
>
> I am sorry that you are so upset Liryna that I decided to create my own
> project instead of continuing to contribute to Dokany. But to go around
> and spread unsubstantiated rumors is not acceptable.
>
> You do not know how many people use WinFsp. To claim that there is no
> feedback is simply false. There is no feedback that you see, but there is
> quite some favorable feedback that I have seen including commercial
> propositions. Furthermore being the number 1 trending project on GitHub
> (for the C language) certainly shows some favorable feedback.
>
> I would strongly argue that WinFsp is stabler and takes file system
> semantic correctness far more seriously than Dokany. I note that you use
> my own file system test suites to test your file systems and that Dokany
> breaks with such basic things like memory mapped files and share access. I
> could enumerate all of Dokany’s failings, but I will spare you the
> embarrassment.
>
> Bill
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]