NTFS is proprietary, so info about that goes on inside can only be deduced from "black box" techniques.
From -
http://www.usenix.org/events/usenix0...html/main.html
"Although the source code or documentation of NTFS is not publicly available, tools for finding the NTFS file layout exist [28].
We ran the Windows XP operating system on top of VMware on a Linux machine. The pseudo device driver was exported as a SCSI disk to the Windows and a NTFS file system was constructed on top of the pseudo device. We ran simple workloads on NTFS and observed traffic within the SBA driver for our analysis.
Every object in NTFS is a file. Even metadata is stored in terms of files. The journal itself is a file and is located almost at the center of the file system. We used the ntfsprogs tools to discover journal file boundaries. Using the journal boundaries we were able to distinguish journal traffic from fixed-location traffic.
From our analysis, we found that NTFS does not do data journaling. This can be easily verified by the amount of data traffic observed by the SBA driver. We also found that NTFS, similar to JFS, does not do block-level journaling. It journals metadata in terms of records. We verified that whole blocks are not journaled in NTFS by matching the contents of the fixed-location traffic to the contents of the journal traffic.
We also inferred that NTFS performs ordered journaling. On data writes, NTFS waits until the data block writes to the fixed-location complete before writing the metadata blocks to the journal. We confirmed this ordering by using the SBA driver to delay the data block writes upto 10 seconds and found that the following metadata writes to the journal are delayed by the corresponding amount."
So NTFS is not a fully journalled file system (and there are different iinterpretations and implementations of "full") - so what? FAT32 has essentially no protection against file corruption and only a second FAT to "protect" against volume corruption (which is doesn't). FAT32
cannot recover from an inconsistent state - chkdsk which just discards anything that doesn't fit the primary FAT (which may itself be corrupt). NTFS can and does recover from inconsistent states, and remarkably well at that.
Roughly, the different kinds of journaling are:
1) data=writeback -- does no journalling of data; metadata only. fastest. data corruption possible in system crash.
2) data=ordered -- strictly speaking only journals metadata but uses transactions to protect data as well. slightly slower than writeback mode. Because of the way the blocks to be written to disk are ordered in this mode, it offers all the protection of full data journalling mode when files are being appended to; corruption is possible when files are being overwritten.
3) data=journal -- full journalling of data and metadata. Should be slowest because data is written twice, once to journal & once to final location. However some tests have shown that its performance surpasses the other two modes in busy interactive environments where disks are being read from & written to at same time. Also requires the largest disk footprint for journal.
So NTFS uses something on the data=ordered model - and so?
"I wouldn't agree that NTFS is better for reliability, in the data recovery sense."
Oh please.....
Finally, "..NTFS security is exactly zero unless you have rock solid physical (access) security..."
With physical access to ANY machine breaking in is trivial. Once in, it may even be possible to recover encryption keys and read 128-bit encrypted files (brute force won't do it). Without physical access to the machine(and assuming not-rooted), correctly set up NTFS permissions make seeing things you ain't meant to exceedingly difficult.
Don't blame NTFS (which is a nicely balanced filesystem) when the poor security model of the overlying OS is the real problem.
I'm not actually sure what you're complaining about to be honest.