Unfortunately this is a common problem with community projects.
Once the community identifies a significant problem, projects pop up to address it. In this case, the problem is NTFS FS utilization.
Linux-NTFS (kernel FS driver), Was created first, and after a while development stalled. IMO a bad choice, it deserved priority and still does. This driver has been stable, read only, for as long as I've done Linux (over half a decade). This only addresses half of the problem, so the community looked anywhere they could.
Captive NTFS (Driver Wrapper for NTFS.SYS), was comparably easier to create. As much code already existed in other projects. The main reason the community looked on, was because NTFS.SYS is not Free Software.
NTFS-3G (Fuse), was slapped together and is fully functional. The project has the driving commercial force of Tuxera. This project addresses the original problem of utilizing NTFS from Linux. Tuxera offers a premium proprietary NTFS kernel driver, which highlights why the community needs to complete Linux-NTFS.
So with the original problem addressed, the community outcry cooled off. Which can be unfortunate, as many times the correct implementation never gets completed. When I think about it, Tuxera actually protected its proprietary kernel NTFS implementation. Creating an inferior FUSE driver, cooled the push for a solid performing GPL kernel driver.
Now just to clarify, I am a huge community project supporter/enthusiast. I just also happen to be a critic, with no kernel programming ability. FUSE has many merits, especially for specialty FS drivers. The cold hard facts still stand, Kernel FS Drivers provide much stronger performance. Writing kernel drivers takes much more time/talent, then a comparable FUSE implementation. Both of which (Time from Talented community Programmers), have always been in short supply.
I hope this explains the current situation, in regards to Linux NTFS support.
2Except that they are written by completely separate projects, and surely it is important for the kernel to have a driver that actually works? – Jack – 2010-05-10T03:13:10.550
The fact that they're separate projects is irrelevant. In fact, that makes it worse since you need to find someone that has both kernel filesystem module knowledge and NTFS knowledge in order to be able to write the kernel driver. – Ignacio Vazquez-Abrams – 2010-05-10T03:16:43.850
1No, it isn't irrelevant.
At the moment the kernel does not have NTFS write support, when it is clearly possible. Instead, a 3rd party solution is needed.
Your answer is akin to saying why bother to develop Gnome, when KDE does the job just fine. It isnt quite an apt analogy, as both gnome and KDE are completely functional, but you get the point... – Jack – 2010-05-10T03:41:04.123
Gnome and KDE also have different purposes. What would a kernel driver do that a FUSE driver wouldn't? – Ignacio Vazquez-Abrams – 2010-05-10T04:16:02.243
3You're missing the point. There are many advantages to having a working NTFS driver in the kernel, without having to rely on a third party userspace driver.
In any case, the answer to my question is not "because ntfs-3g works very well".
If you have Project X and Project Y, both of whic have the same common goal and Project Y gets their first, Projec X is not going to give up. In fact, we see the opposite of that all too often. – Jack – 2010-05-10T19:01:29.720
2
What would a kernel driver do that a FUSE driver wouldn't?: Free up the CPU for other processes on embedded systems by not pegging it at 100%. See Ubuntu, Mageia, Ubuntu, ArchLinux, openSUSE etc. – Amit Naidu – 2014-04-26T07:01:18.153