> think reparse points, alternate streams, transactions, BitLocker integration, and shrinkable volumes, to name a few. NTFS's USN change journal (which is sepa

> think reparse points, alternate streams, transactions, BitLocker integration, and shrinkable volumes, to name a few. NTFS's USN change journal (which is separate from the transaction journal) is also useful as a robust offline alternative to ReadDirectoryChangesW file monitoring. Toy example: https://gist.github.com/pervognsen/bcc610d6a5ae6cbc3b2b4f7aa00d8da9 https://gist.github.com/pervognsen/bcc610d6a5ae6cbc3b2b4f7aa.... Anyway, the problem I've always had when using non-standard file system metadata like alternate streams or sparse files is that they interoperate poorly in practice. There's lots of code and programs out there that wants to treat everything like a plain old file and hence won't preserve alternate streams or sparseness. From my recollections this is true even for several of Windows's built-in utilities. Same issue if you want to transfer files over a socket or pipe or a non-NTFS storage medium like a FAT-formatted USB drive or a NetApp filer or a source control system. As a result this kind of thing is only really useful when deployed in a bubble; I believe WSL uses alternate streams for Unix permission bits and other Unix-specific file properties. Even though those WSL guest files live in a directory tree on a normal NTFS volume, they strongly caution you against touching them directly outside of WSL, presumably for the aforementioned reasons. Aside from features, NTFS has some performance issues compared to other modern file systems, notably with lots of smaller files.