6 ms·

Ntfsplus: NTFS Filesystem Remake

40 points by worble 11mo ago

rwmj 11mo ago
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/ https://pretalx.com/devconf-cz-2024/talk/SN93LG/)
- lproven 11mo ago
  > 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_driver/ 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.
- nly 11mo ago
  There is also a commercial attempt: https://www.paragon-software.com/us/home/ntfs-linux-professional/# 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/ http://www.jankratochvil.net/project/captive/
  - poizan42 11mo ago
    The ntfs3 driver mentioned above is the former proprietary Paragon driver.
tredre3 11mo ago
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!
- rwmj 11mo ago
  Yes, fsck for NTFS has a direct immediate real world usage completing this function: https://github.com/libguestfs/virt-v2v/blob/dda93d7fd3ef5b2cdf25cfefa0b2d41207fa54f6/convert/convert.ml#L281 https://github.com/libguestfs/virt-v2v/blob/dda93d7fd3ef5b2c...
timsneath 11mo ago
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?
- d3Xt3r 11mo ago
  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.
  - comex 11mo ago
    The author probably meant “A well-maintained” instead of “The well-maintained”.
    - creshal 11mo ago
      Was there an author involved at all, or did an AI write this summary?
rekttrader 11mo ago
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.
- lproven 11mo ago
  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.

40 points by worble 11mo ago

rwmj 11mo ago

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/ https://pretalx.com/devconf-cz-2024/talk/SN93LG/)

lproven 11mo ago
> 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_driver/ 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.
nly 11mo ago
There is also a commercial attempt: https://www.paragon-software.com/us/home/ntfs-linux-professional/# 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/ http://www.jankratochvil.net/project/captive/
- poizan42 11mo ago
  The ntfs3 driver mentioned above is the former proprietary Paragon driver.

tredre3 11mo ago

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!

rwmj 11mo ago
Yes, fsck for NTFS has a direct immediate real world usage completing this function: https://github.com/libguestfs/virt-v2v/blob/dda93d7fd3ef5b2cdf25cfefa0b2d41207fa54f6/convert/convert.ml#L281 https://github.com/libguestfs/virt-v2v/blob/dda93d7fd3ef5b2c...

timsneath 11mo ago

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?

d3Xt3r 11mo ago
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.
- comex 11mo ago
  The author probably meant “A well-maintained” instead of “The well-maintained”.
  - creshal 11mo ago
    Was there an author involved at all, or did an AI write this summary?

rekttrader 11mo ago

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.

lproven 11mo ago
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.