[HN Gopher] New NTFS Read-Write Driver from Paragon Merged to Li...
       ___________________________________________________________________
        
       New NTFS Read-Write Driver from Paragon Merged to Linux Kernel
        
       Author : beshrkayali
       Score  : 89 points
       Date   : 2021-09-04 20:15 UTC (2 hours ago)
        
 (HTM) web link (git.kernel.org)
 (TXT) w3m dump (git.kernel.org)
        
       | jumelles wrote:
       | Is this as big of a deal as it seems?
        
       | canadaduane wrote:
       | Does anyone know what confluence of events or motives made this
       | land now? I'm grateful for their work--just curious why a
       | commercial software company decided to make its main capability
       | available for free.
        
         | kasabali wrote:
         | A bit more context:
         | https://arstechnica.com/gadgets/2021/08/paragon-is-working-t...
         | 
         | So just as a guess, maybe after Samsung's exfat code was merged
         | into mainline, license and support revenue of their own exfat
         | driver took a hit. So they decided it's in their interest to
         | preemptively get their own ntfs driver in mainline thus they
         | can get more support contracts this way?
        
         | ch_123 wrote:
         | There's an official statement here:
         | 
         | https://www.paragon-software.com/home/ntfs3-driver-faq/
         | 
         | Reading between the lines, I suspect that the effort of
         | maintaining an out-of-tree file system outweighed any money to
         | be made from selling NTFS support to Linux users, especially
         | when ntfs-3g is probably good enough for many use cases. They
         | have a lot of other products, and it's possible that some of
         | them leverage this NTFS support as well.
        
           | m4rtink wrote:
           | Anything out of the kernel source tree is pain in the ass for
           | many reasons, ranging from a nuisance to impossible to use
           | due to tainted kernel nullifying OS vendor support
           | guarantees.
        
       | azinman2 wrote:
       | I'd love to know once this is merged and has journaling if there
       | are advantages to use NTFS instead of ext4 or other file systems
       | as your main Linux FS, versus interop with windows drives.
        
         | Kenji wrote:
         | NTFS is shit. Ext4 is better in every single way, _especially_
         | performance. Ditch the Windows shit if you can.
        
         | generalizations wrote:
         | IIRC, NTFS doesn't support permissions.
        
           | Flimm wrote:
           | NTFS actually does support permissions, it's Windows that
           | doesn't. NTFS also supports symbolic links and hard links.
        
             | tbrownaw wrote:
             | Um, I've had plenty of times I got a UAC (~windows sudo)
             | prompt trying to access files I didn't have permissions to.
        
             | nolok wrote:
             | Not contradicting just genuinely wondering, what do you
             | mean by windows doesn't? I have different permissions setup
             | for various users on different folders on ntfs volumes in
             | regular windows 10 installs. Or do you mean another sort of
             | permissions?
        
               | zamadatix wrote:
               | In this context they are talking about the POSIX
               | permissions related to running Linux on the drive which
               | NTFS supports but Windows does not use. Instead Windows
               | uses another attribute pointing to their security
               | descriptor model which is also used by other non-file
               | objects throughout the OS.
        
           | zamadatix wrote:
           | config NTFS3_FS_POSIX_ACL
           | 
           | bool "NTFS POSIX Access Control Lists"
           | 
           | depends on NTFS3_FS
           | 
           | select FS_POSIX_ACL
           | 
           | help
           | 
           | POSIX Access Control Lists (ACLs) support additional access
           | rights for users and groups beyond the standard
           | owner/group/world scheme, and this option selects support for
           | ACLs specifically for ntfs filesystems.
           | 
           | NOTE: this is linux only feature. Windows will ignore these
           | ACLs.
        
           | [deleted]
        
       | rubyist5eva wrote:
       | Looking forward to testing this out with games installed in my
       | Windows partition. Hopefully won't need to have a dedicated
       | partition for Linux games anymore.
        
         | compsciphd wrote:
         | why couldn't you have used ntfs3g before then in read-only
         | mode. or even the only ntfs in kernel code in read only mode.
        
           | zamadatix wrote:
           | Some games flat out won't work with read only and for the
           | ones that do if they are still receiving regular updates it's
           | going to be a PITA. Also a PITA when you want to add a new
           | game.
           | 
           | Not to mention both ntfs-3g and even the previous kernel
           | driver weren't exactly performance marvels.
        
       | jtvjan wrote:
       | Now all that's left is for Microsoft to add EXT support to NT.
        
         | xook wrote:
         | There are third party tools to read from Ext partitions, but
         | unfortunately, writing to the filesystem seems to be a footgun
         | roulette situation.
        
         | zamadatix wrote:
         | Since they've went the way of having WSL2 physical mounts show
         | up in \wsl$ this summer I don't think there is much push for
         | native <pick your FS> support.
         | 
         | https://devblogs.microsoft.com/commandline/access-linux-file...
         | 
         | Would definitely be cool but Linux supporting NTFS only makes
         | it even less necessary on top of that.
        
           | Namidairo wrote:
           | You can only mount entire physical disks under WSL2 though,
           | as opposed to single partitions, which makes it a showstopper
           | depending on your layout. (Common single disk configurations
           | like a laptop/ultrabook come to mind)
        
           | ecnahc515 wrote:
           | I hadn't considered how this being in the upstream kernel
           | would make it possible to run my WSL2 on NTFS natively.
           | That's pretty cool. I'm sure there's still some stuff to
           | figure out, but still pretty awesome.
        
             | phkahler wrote:
             | Doesn't WSL2 already have the ability to read NTFS somehow?
             | Isnt this just an optimization?
        
               | flatiron wrote:
               | It's a network mount. Hence it's "don't use it cause it's
               | shitty" reputation.
        
             | zamadatix wrote:
             | Well you could do that too but you'd lose permissions
             | between the two (NTFS supports POSIX permissions but Linux
             | doesn't and vice versa with Windows permissions).
             | 
             | The blog post is really about making any Linux mountable FS
             | available to the Windows side of WSL2 without NT needing to
             | support it. E.g. it doesn't matter if the drive is NTFS or
             | Ext4 or BobYourUncleFS as long as the Linux kernel can
             | mount the FS you can mount it in WSL2 and access it from
             | Windows without NT needing to support the OS. It also
             | already works in reverse, volumes mounted in Windows
             | (including NTFS) can also be shared with WSL2.
             | 
             | It's really just their integrated-into-the-OS version of VM
             | guest filesystem sharing.
        
       | dataflow wrote:
       | Does this mean we can boot from Linux from NTFS from mainline
       | now?!
        
       ___________________________________________________________________
       (page generated 2021-09-04 23:01 UTC)