Paragon Sends Out Latest NTFS Read-Write Linux Driver Patches

[phoronix]

Phoronix: Paragon Sends Out Latest NTFS Read-Write Linux Driver Patches

Back in August was the big surprise of file-system driver vendor Paragon Software wanting to mainline their NTFS driver into the Linux kernel that is much more advanced than the existing NTFS Linux driver. While not merged yet, on Friday the latest version was sent out for review...

http://www.phoronix.com/scan.php?page=news_item&px=NTFS-Linux-Driver-V8

[skeevy420]

And there goes all the space saved with the removal of the PPC code

I can't wait for this to go mainline so I can mount my Windows 10 root w/o needing userspace drivers. I just want to easily and speedily copy games from Windows to Linux.

And to see Root on NTFS tutorials appear. I have to imagine that dual booters will love NTFS on Root to get their Linux data back on to Windows without putzing around with an in-between data drive layer.

[lumks]

Actually, yes. Root on NTFS, with a systemd-homed secured $HOME might have the potential to kill ext4 for many people.

[uid313]

And to see Root on NTFS tutorials appear. I have to imagine that dual booters will love NTFS on Root to get their Linux data back on to Windows without putzing around with an in-between data drive layer.

Actually, yes. Root on NTFS, with a systemd-homed secured $HOME might have the potential to kill ext4 for many people.

The ext4 driver is much more mature and proven than the NTFS driver.
The ext4 file system might just better than NTFS too, at least more suitable for Linux due to POSIX file system semantics.

I don't think NTFS is going to take over as root file system, but its nice to able to mount other partitions.

[birdie]

I don't think NTFS is going to take over as root file system, but its nice to able to mount other partitions.

NTFS has all the capabilities to serve as a root fs for Linux and in many ways it's more preferrable since it offers transparent compression and per file encryption out of the box. The latter is still not possible with ext4.

[uid313]

NTFS has all the capabilities to serve as a root fs for Linux and in many ways it's more preferrable since it offers transparent compression and per file encryption out of the box. The latter is still not possible with ext4.

But ext4 is a POSIX file system so it have like rwxrwxrwx on its CHMOD, so its rwx for user, rwx for group, rwx for world. Does NTFS have?
On NTFS all files are executable, but on Linux only the files that have the permission +x are executable. I don't think NTFS has any concept of +x.

[S.Pam]

But ext4 is a POSIX file system so it have like rwxrwxrwx on its CHMOD, so its rwx for user, rwx for group, rwx for world. Does NTFS have?
On NTFS all files are executable, but on Linux only the files that have the permission +x are executable. I don't think NTFS has any concept of +x.

NTFS supports POSIX permissions, hard and soft links . https://askubuntu.com/questions/1184...%20is%20needed).

I rather use Btrfs though

[darkbasic]

What prevented ntfs-3g (the userspace driver) to be ported to kernel space instead?

[onlyLinuxLuvUBack]

NTFS has all the capabilities to serve as a root fs for Linux and in many ways it's more preferrable since it offers transparent compression and per file encryption out of the box. The latter is still not possible with ext4.

The filesystem in temple-OS is better than NTFS, why not run that instead?

TempleOS > every os made by man....

The RedSea file system does not allow files to grow because it only has an allocation bitmap and not a FAT table. This "flaw" is by design. I am intentionally crippling this operating system, making it a toy with the wisdom that this will prevent commercialization and corruption. The toy spirit of the operating system will be preserved going into the future. The vision for this operating system was a modern Commodore 64, which was a fun toy.

Doing whole file operations is the TempleOS way of doing thinks. It is the simplest and, ironically, the fastest. It is obnoxious in the characteristic way that TempleOS is obnoxious, flaunting massive modern resources in a way that makes old programmers protest.

Doing whole file operations will sabotage efforts to change the 640x480 resolution and violate the ban on multimedia. When doing large, whole-file operations, immediately memory fragmentation is a serious problem, but not so for allocations in the range under a Meg (with occasional larger ones).

The file compression scheme in TempleOS only works on whole file operations and the DolDoc format cannot have text tacked onto the end, since binary data is at the end.

I don't want to spoil fun, so of course I offer a way to get awesome performance that is, ironically, superior. FBlkRead() and FBlkWrite() allow you to read a block offset from the start of a file. Since files are all contiguous, this is incredibly efficient. You just have to declare the desired file size when you create it with FOpen() and cannot change it. See ::/Demo/Dsk/DataBase.HC.

If you like, you are encouraged to to do raw BlkRead() and BlkWrite() directly on a drive. Just get a pointer to a CDrv with Let2Drv() and you are on your way! Your computer is supposed to be a fun toy! You can make an entire partition used for a database, or invent a file system.

On the whole, the RedSea file system with its whole-file-only limitation bring beautiful harmony. It beautifully captures the spirit of TempleOS with simplicity and, ironic speed, since contiguous is fastest.

• "Commodore 64" is a trademark owned by Polabe Holding NV.

https://www.reddit.com/r/programming/comments/5s7wu4/templeos_red_sea_file_system_and_block_chains/

[You-]

What prevented ntfs-3g (the userspace driver) to be ported to kernel space instead?

Someone to actually do that work.

I cant remember precisely, but I think the developer was at some point hired by Apple. I dont know if there has been much development on it since then. (or that might have been the developer for ntfsprogs...)