I think this is the fourth attempt at an NTFS implementation for Linux.

The first was the classic, abandoned NTFS kernel driver. It was removed from the kernel last year, but used to be found in fs/ntfs.

The second is FUSE-based ntfs-3g / ntfsprogs (which is the one which is most reliable). Unfortunately this is basically abandoned upstream.

The third is the fs/ntfs3 kernel driver, which we found in testing to be quite unreliable, although I was hoping it would improve.

Why I'm interested in all this is because reliable NTFS support, including writes, is vital for our virt-v2v product (https://pretalx.com/devconf-cz-2024/talk/SN93LG/)

There is also a commercial attempt:

https://www.paragon-software.com/us/home/ntfs-linux-professi...

and even an attempt at wrapping Microsofts implementation (dead project):

http://www.jankratochvil.net/project/captive/

The ntfs3 driver mentioned above is the former proprietary Paragon driver.

> The first was the classic, abandoned NTFS kernel driver.

Of which this is v2, an enhancement with R/W.

https://www.theregister.com/2025/10/21/ntfsplus_new_rw_drive...

IOW: not abandoned after all. Revived and improved, in ways I describe in the article above.

I was very hopeful for ntfs3, but unfortunately I think it was doomed from the start because of the ill blood built during the initial "code donation" regarding code quality, egos, and general stability.

Ntfsplus looks very promising based on this email and what's been done already. Something as "simple" as writing an fsck utility (something linux never had for ntfs) tells me that the author actually cares about real world usage. And that makes me very hopeful!

Yes, fsck for NTFS has a direct immediate real world usage completing this function: https://github.com/libguestfs/virt-v2v/blob/dda93d7fd3ef5b2c...

I didn't understand the introduction here, which says both:

> The well-maintained NTFS driver in the Linux kernel enhances interoperability with Windows devices

and

> Currently, ntfs support in Linux was the long-neglected NTFS Classic (read-only), which has been removed from the Linux kernel, leaving the poorly maintained ntfs3.

Is it well-maintained or long-neglected? Or am I misunderstanding this?

I think the author made a typo (or was trying to be sarcastic and missed the sarcasm quotes around "well maintained").

I've used all NTFS drivers extensively in Linux, and whilst ntfs3 is maintained with somewhat regular commits, they are often pretty sparse and haven't addressed some of the long-standing issues (eg Bonnie++ and some other disk benchmark tools fail) - the biggest issue being the lack of a decent fsck tool in the entire ecosystem (ntfsfix in the ntfsprogs pkg isn't a real fsck).

Personally I'd still be wary of doing any fsck from this new project for a good wee while and would recommend using the real CHKDSK from a Windows or a WinPE install instead. Of course, the best option is to avoid using NTFS altogether and use a well-maintained native Linux fs.

The author probably meant “A well-maintained” instead of “The well-maintained”.

Was there an author involved at all, or did an AI write this summary?

Why can’t MSFT in their infinite wisdom get someone from the WSL team to build a native driver. It would add so much good will.

1. Because MS's support for Linux is just marketing, nothing more.

2. Because a VM can't mount a volume on the host which is already mounted. Having volumes only accessible to VMs is little use when the VM has its own native formats for that.