Is it like https://dokan-dev.github.io/ ?

If not, how does it differ?

For comparison probably a good start is the API (I'm somewhat familiar with dokan, used it several years ago for some project)

https://github.com/billziss-gh/winfsp/blob/master/inc/winfsp...

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

It's really the edge cases that one might run into, where things no longer work well, but I don't recall right now into what problems I've run into (What I did was for the xbox360 devkit to read files from my HDD, rather to copy to it, as was required by the sdk, but I've achieved only 5mb/s, while copying was 10mb/s - the only benefit was if you wanted to read on demand, a bit and for fun).

Sony later used dokan for their devkit in PS4 I think? just found some info here: http://www.psdevwiki.com/ps4/File_System_Driver

There is also CBFS from Eldos -> https://www.eldos.com/cbfs/ - (commercial)

I have not looked at the technical side, but one big thing is the license. Dokan is LGPL (the library is LGPL, the driver GPL). This one is released under the AGPL, though. :-(

I'm curious whether anyone had ever tried implementing a pure userspace solution (without a kernel driver) by basically exposing the underlying FS as a CIFS share on some random local port. Obviously, that would be slower, but for many applications that doesn't matter much - while the ability to install and run without administrator privileges would be valuable.

This is how CDRom worked under DOS(MSCDEX).

from wiki:

>The driver uses the Microsoft Networks interface in MS-DOS. This is the reason that at least version 3.1 of MS-DOS is required. The driver essentially looks like a network drive from the system perspective. It's implemented as a TSR program[3] and an extension to the redirector interface (CDEX).

OpenAFS used to do this if I remember right. They moved to an IFS.

How do I connect to CIFS on non-default port?

The only way I found was to use (cygwin ssh) port forwarding to map that port to the standard one, kill the default network SMB process (which restarts), and hope my process wins the race. Then you could access the remote shares at \\127.0.0.1 .

I think I also managed to create a loopback device, put it into its own subnet, and map the port to that device, and then it was possible to do e.g. \\192.168.100.56, but it was a pain to set up.

The reason I needed this was, I wanted to run samba as non-root on a remote host (on a non-privileged port), and forwarded that with ssh though a firewall. This way I could access my files on the remote Linux server from my windows desktop. One problem is that windows does not tolerate hanging connections much, and a bad or lost connecting can freeze your program or require a reboot. I'm not sure how much is the kernels fault and how much you can code around this.

Dirty hacking as it is. In similar situations I just use SFTP.

I've seen UNC paths with port number before, so I assumed that it's possible; but apparently those are for WebDAV.

Of course, this means that it should be doable with WebDAV instead of CIFS. Which would probably mean even worse perf, but still potentially acceptable...

Can WebDAV paths be used without mounting them to a drive letter first, though?

I've done this, it works.

On Windows? I didn't think Windows would connect to SMB/CIFS on any other ports other than 139/445.

Can you share any other details?

Not sure you can do it easily with SMB/CIFS (maybe some NAT tricks) but depending on the level of FS support you want it's pretty easy to do it with WebDav. You can mount a webdav share pointing to localhost on an arbitrary port (I believe it's of the work \\localhost@portno\DAVWWWRoot). From there I'm sure you could proxy out to any other FS implementation you liked. It also probably isn't great for large files etc due to the way WebDAV works of course :-)

For this particular client we had Administrator access. SMB was used since we did not trust Dokan and did not want to pay for CBFS.

For those interested in the same workflow demonstrated on demo GIF, there's Win-SSHfs, built on Dokany. This fork works pretty well:

https://github.com/mfrnd/win-sshfs

I'm wondering what the rationale is for the usage of `goto` in the C source? It looks like it's exclusively used to implement a pattern of exiting or failing early and in a common way. Is this something that's common in modern C?

I'm not entirely sure how common it is in modern projects, but I use it a lot. I find functions that use this kind of centralized cleanup code a lot easier to read than functions that avoid 'goto' by duplicating the cleanup code or handling errors with deep nested if blocks. The Linux kernel coding style guide recommends it as well (see "Centralized exiting of functions" in https://www.kernel.org/doc/Documentation/CodingStyle)

FWIW, it seems to be the primary use of 'goto' in these projects: https://github.com/torvalds/linux/search?q=goto https://github.com/FFmpeg/FFmpeg/search?q=goto https://github.com/antirez/redis/search?q=goto

Yes, goto exit and cleanup resources on error is a common and not frowned upon idiom in C. See Python source.

Or the Linux kernel.

(Or Apple's "goto fail" bug for a somewhat infamous example how to not use it.)

> Or Apple's "goto fail" bug for a somewhat infamous example how to not use it.

But that problem was not because of the goto, strictly speaking.

I dont use "goto" in C but a specialized static function that does more or less the same thing. Example is the zuluExit "goto" function: https://github.com/mhogomchungu/zuluCrypt/blob/master/zuluCr...

I don't think that solution works well in general. If you want to do cleanup of local variables, I don't see how you'd do that with a static function unless you're using globals everywhere, some awful god object, or terrible varargs hacks.

I am late to the party as I just found out about this discussion. I am the author of WinFsp. You can ask me specific questions if you want.

Bill Zissimopoulos

Why not FUSE itself? I wonder if the Windows Subsystem for Linux guys could get FUSE working.

WinFsp does have a FUSE API. It implements the FUSE 2.8 (high-level) API. This is in addition to its native API. I also have a FUSE package submission to Cygwin. It needs votes :)

https://cygwin.com/ml/cygwin-apps/2016-07/msg00041.html

Bill Zissimopoulos

"WinFsp is available under the AGPLv3 license. If you find the constraints of the AGPLv3 too onerous, a commercial license is also available. Please contact Bill Zissimopoulos for more details."

I hope they will soon switch to MIT.

"Hey, could you make your free thing even free-er so I can make money with it in your place?"

"...so I could make a non-free derivative/build?"

Fixed it for you. A lot of people make money by working (or integrating) strongly copylefted software, with results remaining friendly to end-user freedoms.

> "remaining friendly to end-user freedoms"

.. which isn't quite the same thing as itself being Free software. Not that I want to start the license war here.

Both MIT and AGPL are Free and Open Source Software licenses, by the very official (FSF and OSI) definitions. I don't think there's any need to disagree here.

One provides a way to create a proprietary non-free derivatives/builds, granting more freedom to the non-end-user developers who use the code. Another provides a way to ensure end-users always have certain freedoms.

Debating which is better is meaningless, as it's just a matter of personal preference. We should avoid that.

I'm curious. What are examples that are not based around offering what the software does as a service (including support / consulting based products)?

I believe, every day, a lot of FOSS projects get forked by engineers (who are getting paid for their work). They add new features or fix bugs they've encountered, and share their work results back upstream. Or release as their own fork/patchset (I stumble upon such forks almost every day I browse GitHub/Bitbucket/GitLab).

Say... for an example that resembles the OP project... In a company I work for, we have a FUSE-based (GNU/Linux) filesystem that we use to access Azure Blob Storage like any other mounted network share. A puny tiny project that's a fork of someone else's fork of someone's project, all FOSS (Apache2-licensed, though, not *GPL, but I believe it's irrelevant here), but hope it should still suffice as a quick example. There's literally no reason for us to keep it secret - we're end-user ourselves, enjoying cp and rsync working nicely. Well, maybe not completely nicely - I'm aware there are still some issues with that filesystem, but at least, with the patches, it works OK for us. So, sure, we've put all our changes on GitHub. And, I'm sure, every our developer who had touched the code to solve the problems we had with it got paid for their time. :)

So, I guess, it's every time the engineer is an employee of a company that's an end-user themselves. I think the only case where GPL/AGPL doesn't fit is when you license the software to the end-users to run, and you don't want them to re-distribute and modify software on their own but rely on you for all their needs. And it seems that original project author doesn't fancy this particular business model.

I completely agree with you - mainly because you're making the same point as I did: OP didn't want other people making licensing money with his software, so he copylefted it. GP didn't like this - at which point I was making the point that apparently he'd like to get in on licensing money (of derivative works), without giving OP a fee. Because, as you described, that's pretty much the only case where OP's model wouldn't work. What you described IMO fits into what I was saying - you can make money on GPLed software just fine, if it's based around services or consulting, even if it's just for internally used services (because internal customers are customers too - you could even be your own customer).

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

Some good points here. I admit that I do not fully understand all consequences of licensing this under the AGPL vs the GPL (and I mean social rather than legal).

On the question of why AGPL/GPL and not a more free license like BSD: when I started out the project my intention was to place it under a BSD license. But after working on it for 4-5 months and writing about 25-30 KLOC, with much of it being kernel-mode code I had to reexamine the licensing decision. I did not want to go back on my decision to open source the project, but I also felt that I should see something out of all this hard work (believe me when I say that Windows kernel mode is not fun).

Bill Zissimopoulos

This attitude is why we can't have nice things. The author is obviously making a very conscious choice. Respect that!

"Respect that!"

Preference for the MIT license and a wish that the project will reconsider is meant as no indication of a lack of respect. I am sorry you took it that way. This is too good a project not to be under MIT.

Licenses other than AGPL-3 are available, as you quoted yourself. Just contact Bill Zissimopoulos for more details. By complaining here you're leaving the impression that you're not interested in any arrangement other than Bill giving you a more liberal license for free.

> This is too good a project not to be under MIT.

In my opinion, good projects like these should always be copylefted. Large projects under liberal licenses are essentially donations by the free software community to proprietary software companies. This results in such companies being able to take advantage of their users in unethical ways using your software. The one thing that free software developers have over proprietary software developers is that we can use copylefted software. It maintains user freedom and maintains the competitive advantage that free software companies and communities have over proprietary software companies.

I hear what you are saying.

Personally, as a contributor to open source, I would like my contributions to go to projects that enable and encourage business. I prefer not to make code contributions to projects that cannot freely be used by all, including business. I consider that to be the spirit of open source.

Sure, some businesses will take advantage of Node.js for example because it has an MIT license, but the vast majority will benefit. Startups that build on open source can be more efficient, for the benefit of the customers those businesses exist to serve, honorably, at a profit.

> I hear what you are saying.

I don't think you do, because all you talk about is how lax free software licenses mean businesses can make money. That's a misunderstanding of how copyleft licenses work. No free software copyleft license says you cannot make money.

> I would like my contributions to go to projects that enable and encourage business.

Many businesses use and develop free software under copyleft licenses. They sell support contracts, it's a very standard model and nothing new.

> I prefer not to make code contributions to projects that cannot freely be used by all

Copyleft's only restriction is that distributors have to respect the freedom of the people the distribute software to. If you're not a distributor, you don't care. If you're a company that distributes proprietary software and cannot even consider distributing free software, then honestly I wouldn't want my software to be part of your products. It's as simple as that.

My main concern is the users of my software. I want to make sure that no distributor or developer can take away the freedoms I intended them to have, and that's what I care about.

> Startups that build on open source can be more efficient

And what's wrong with that free software being copyleft in that instance? They are taking advantage of very large amounts of human effort to be "more efficient". The least they can do is make their modifications freely available to people they give their software to. And even better would be if they realised that liberating their software is a net benefit to everyone involved. But most startups (unfortunately) don't care about software freedom.

> honorably, at a profit.

No part of any free software license requires that you cannot charge money for the software or services. Nor does any free software license state that you cannot make a profit. These are strawmen.

"But most startups (unfortunately) don't care about software freedom."

I think most startups do care, and have cared. And even if some didn't, then I wouldn't want to introduce any potential for them to be forced on the issue with a lawsuit.

What do you think of the ZFS/Linux licensing issue? Surely ZFS would have seen broader adoption if not considered a derivative of the kernel by the GPL?

> I think most startups do care, and have cared.

Maybe since I'm not in that space, that's why I haven't have seen that.

> What do you think of the ZFS/Linux licensing issue?

I am sad that Sun decided to make a GPL-incompatible license. However, a better question is "would there be proprietary ZFS forks if ZFS wasn't under a copyleft license". I can think of at least one company that would have such a fork and that alone is worth not making it permissively licensed. Same argument goes for DTrace, which has been ported to several proprietary operating systems (but you can get their modified versions of DTrace). At the same time, the CDDL isn't as strong as it should be but it's inconvenient enough that practically most companies won't bother to make a proprietary fork.

Overall, while it sucks for the GNU/Linux community IMO the net benefit for free software is greater (you can use illumos or even FreeBSD which incldues ZFS).

> if not considered a derivative of the kernel by the GPL?

I don't think anyone thinks of ZFS as a derivative work of the Linux kernel. The translation layer definitely would be, but nobody could seriously think a project almost as old as Linux and developed completely separately would be classified as a "derivative work" of Linux. DTrace is a separate topic.

"I don't think anyone thinks of ZFS as a derivative work of the Linux kernel."

Yes, I wouldn't have thought so either, but the legal technicalities hinged on this, and this was the opinion of many, including Richard Stallman. He stated there was no way that ZFS could be bundled with a Linux distribution without infringing on the GPL. Ubuntu sought separate legal opinion and concluded differently. They are now shipping ZFS as part of their distribution. I think this is an example of why some people are averse to the GPL. Right-spirited use of GPL software could risk exposure to a lawsuit. I guess this could be called the "ten foot pole" argument in favor of more permissive licenses.

> Right-spirited use of GPL software could risk exposure to a lawsuit.

Users of GPL'd software will never be sued. It's developers and distributors that choose to create software using components with conflicting licenses. In my opinion, the benefits for users far outweigh the annoyances of developers.

The reason Richard Stallman presumably claims that ZFS is a derivative work is because otherwise the strength of the GPL would be perceived as being weaker. It was a political play IMO, not one from the standpoint of ethics. Though, it would be fair to say that if you create a translation layer for Linux that would be a derivative work of Linux but because of how it would be used it would also require licensing ZFS under the GPL (because the two pieces of software are intricately linked). So it's possibly true that there would be an effective violation of the GPL.

> I guess this could be called the "ten foot pole" argument in favor of more permissive licenses.

On the other hand, users are also not protected from developers or distributors creating modified versions of your work that are not free software. I guess that could be called the "protection of freedom" argument in favour of stronger copyleft licenses.