Ntfsplus: NTFS Filesystem Remake
lore.kernel.org
lore.kernel.org
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/)
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.
https://www.paragon-software.com/us/home/ntfs-linux-professi...
and even an attempt at wrapping Microsofts implementation (dead project):
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!
> 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'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.
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.