How does Linux kernel deal with Windows NTFS filesystem?

Question

I am reading a text (R. W. Smith LPIC_1 study Guide) that says:

Linux can reliably read NTFS and can overwrite existing files, but the Linux kernel can’t write new files to an NTFS partition.

What does it mean that the "kernel" cannot write new files to an NFTS partition?

In another place it says:

NTFS-3G is a read/write NTFS driver that resides in user space rather than in kernel space. It’s used as the default NTFS driver by some Linux distributions.

How is kernel space different from user space?

Also, as we have access to Windows drives in dual-boot systems, why can't we see the Windows filesystem's type with commands like df -T?

Answer 1

That there was no proper read/write NTFS support before NTFS-3G. Initially, on a dual boot system, it was possible to write a file on an NTFS partition, but on rebooting, under Windows NT/XP, you would have to do a filesystem check to get the (meta) data on disc corrected. It was therefore common to have a VFAT partition for data exchange between Windows NT/XP and Linux, as the driver for that filesystem type did not have this limitation/problems.

Since the introduction of NFTS-3G (2006) this is no longer necessary and you can write new files and update existing ones, reboot under Windows and use those files without doing a filesystem check. (By that time I had largely dispensed with rebooting and was using Windows in virtual machines instead).

NTFS-3G runs in user space, that means that it doesn't have direct access to kernel data and routines, but has to go through system calls like any normal program (and in contrast to a kernel space (device) driver).

As for df -T, that seems to operate with Fuse and that (correctly) identifies the filesystem type as fuseblk. Fuse doesn't know anything about NTFS so it doesn't provide any deeper probing. Neither does df -T probe the disc, it just asks the filesystem driver, what type it is handling (if it could, you would not have to mount a filesystem for it to show up in df -T, in that case it could just probe the device blocks directly and make a guess).