Arch Linux User Repository

Note: the driver was merged to the upstream kernel in 5.15. So this package is useless for Arch official kernels.
If you want bleeding edge updates, use ntfs3-dkms-git.

Readme
More info and tips
How to use DKMS modules
Paragon NTFS3 FAQ

I made some test using bonnie and pts, this driver seems to be much faster than ntfs-3g

http://moodle.math.sk/~doug/bonnie_ntfs3_paragon.html

http://moodle.math.sk/~doug/bonnie_ntfs-3g.html

(disregard the read tests, since they were done from page cache)

edit: compilebench in pts, now includes native ext4, the paragon ntfs3 driver performance is comparable

https://openbenchmarking.org/result/2009092-NE-NTFSCOMPA56

This driver damaged two of my NTFS partitions after a power outage. Even windows' chkdsk couldn't fix them. Thankfully I didn't have anything too important on them.

Please don't use this crap if you care about your hard drives.

Well, I've improved the package, the legacy patch applies at DKMS build stage. So now you should be able to pre-build it anywhere and also update through 5.12 boundary (e.g. 5.11 -> 5.12) on the fly without problems.

@Saancreed, maybe, if I will figure out how to do it properly.
But yeah, seems like this thing causes some problems. Now I'm starting to think that the maintaining of the backport wasn't the great idea.

Hey there!

I've taken a look at PKGBUILD, and I've noticed that in prepare function you check for the version of the kernel currently running on the build machine. This introduces a hidden dependency on build environment, has a chance of outright not working if the machine on which the package is installed is running a different kernel version and DKMS will most likely fail to build the module if the machine has both LTS and mainline kernel (which defeats the point of using DKMS). Could you please move the check to when the module is actually compiled for given kernel version? Y'know, using the usual #if LINUX_VERSION_CODE < KERNEL_VERSION(x, y, z) like Nvidia and other out of tree kernel modules usually do.

My own package achieves it like this:

    patch -Np3 -DNTFS3_NO_USERNS -i "${srcdir}/v${pkgver}-no-userns.patch"
    sed -i '8s:^:#include <linux/version.h>\n\n#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 12, 0)\n#define NTFS3_NO_USERNS\n#endif\n\n:' ./ntfs_fs.h

One can monitor the udisks2 path regarding ntfs3 in this GitHub issue.

Basically, they're rightfully waiting to see what the final name of the merged driver will be. It is my hope that it will replace the old ntfs driver soon.

Recomended trick seems not to work for me (Manjaro, after reboot and udevadm control --reload-rules). /etc/udev/rules.d/99-ntfs.rules SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="ntfs", ENV{ID_FS_TYPE}="ntfs3"

Veracrypt mount shows error (password for encryption is right), mount /dev/mapper/veracrypt1 /mnt/veracrypt1 mount: /mnt/veracrypt1: unknown filesystem type 'ntfs'

Yeah actually your version is better, it'll break when 6+ comes around as you say, but surely ntfs3 will be merged sooner that that (I hope, haha) and in that case you can just depend linux < (version where merge happened) or something

@jpegxguy, I don't think so. Because e.g. "4.20" will not pass the test.
My code also can be problematic tho, when 6+ will come out. But until then I think I will come up with a better idea for checking.

Good idea!

Maybe in line 52 you want [ $kmaj -le 5 ] && [ $kmin -lt 12 ] ?

I've decided to make the package universal. Just to keep support for old/lts kernel version users.
It is now automatically detects kernel version and decides to apply the compatibility patch or not.