FAT 32 on NTFS partition

if you filled in the details for me.

Kees

Not going to go into great detail, because there's plenty of the gory details written by people far more versed than I on the topic, but a bit more on the subject I'll do.

FAT and NTFS largely work the same, so it's kind of easy to assume all file systems work that way. Their design is pretty simple and straightforward. FIFO style placement of files on the HDD, which leads to fragmentation, cluster based storage, and files are just kind of big binary globs.

A good example of something different would be Apple's HFS+. In the pre-OS X days, every file on a Mac was split into two parts, known as the data fork and resource fork. The resource fork held the metadata about a file. So, things like the creation date, last modified date, program association, file icon, etc... The data fork held the actual contents of the file. The text of a word processing document for example. This was why it was always so tricky to convert files from a Mac to a PC, because the PC wouldn't know what to do with the resource fork data.

I believe IBM's OS/2 did something similar to Apple's HFS+ with its HPFS. Things like program associations weren't handled by extension, like with Windows, but rather a bit of metadata code embedded into the file itself.

Another big thing in file system design has been what's known as journaling. In a highly oversimplified way, this basically means that the filesystem tracks changes you make to files, so if the system crashes and a file becomes corrupted, there's some kind of record of what it's previous state was like. This involves two steps, which elude me at the moment. I do remember that NTFS (as of about Win2K) was called a journaling filesystem by Microsoft, but it really only did one of the two steps to be a full journaling filesystem. I don't know if they added the missing bit in XP or Vista, but my guess would be not.

Most recently, the big thing in file system design has been to incorporate ideas from relational databases. This can make for much more efficient use of storage space, faster searching, etc. ReiserFS is probably one of the best examples to look at for this sort of thing. Microsoft even got in on things with WinFS, which started life as a database powered filesystem replacement for NTFS. Then it got scaled back to being a metadata overlay to NTFS, then it was chucked overboard from the sinking U.S.S Vista, and eventually it found its way into becoming part of SQL Server.

If you want to know more about how filesystems work in all the eye glazing and mind numbing glory, I'd suggest looking at the documentation for some of the Linux fileystems like Ext2, Ext3, and ResierFS. You can have hours of incredibly geeky discussions with people who actually work on these filesystems. Getting into as specific a detail as you want.

making claims such as "FAT and NTFS largely work the same..." which is akin to saying that wet and dry are much the same.

Sometimes it pays to go into a bit of detail to avoid making inane statements. It would include information that file writes are different (FAT being a lazy write file system in NT while it is a careful write file system in DOS and NTFS being a recoverable file system (combining the speed of lazy write with the consistency of standard transaction logging for virtually instant recoverability) and that file storage is different (small folders and files can fit entirely within the MFT making their reads virtually instantaneous while FAT REQUIRES that the whole folder structure has to be walked to locate the file before it can be read.

Multiple data streams might be mentioned (in addition to extended attributes in general) as another of many differences that completely disrupt your idea that "FAT and NTFS largely work the same...".

Kees was pretty much on the money with his initial response if one doesn't want to get into detail.