> Operating systems could support START TRANSACTION on filesystem operations, allowing multiple operations to be performed atomically and with isolation
Windows supports that since Windows Vista [1], and at least back then it was used by Windows Update and System Restore [2]. But programming languages usually only expose the lowest common denominator of file system operations in easy APIs, so approximately nobody uses it. Also, it's deprecated by now.
But maybe someone here has deeper insights in what went right and wrong with that implementation, because on the surface it looks like it would erradicate entire classes of security bugs if used correctly.
I don't know the answer, but I'd suspect the following: nobody in storage business cares about what Microsoft is doing beside Microsoft themselves. From storage perspective, supporting Microsoft is always a huge pain. Most of those who do provide support try to limit it to exposing SMB server. I had a misfortune to try to expose iSCSI portal to Windows Server. Luckily, the company was in its relatively early stages where they could decide what things they want to support, and after couple months of struggle they just decided to forget Windows existed.
So, I think, this feature, just like WinFS, and probably ReFS after it, will just end up being cancelled / forgotten. The kind of users who use Windows aren't sophisticated enough to want advanced features from their storage, but support and development of this stuff is costly and demanding in other ways. If they cannot sell this as a separate product that runs independently of Windows, there's no real future for it. The only real future for Windows seems to be Hyper-V, but hypervisors, generally, have very different requirements to their storage than desktops. Simpler in some ways, but more demanding in other ways.
So, bottom line: it probably didn't see any use because the audience wasn't sophisticated enough to want that, and they couldn't sell it to the audience that was sophisticated enough, but was also smart enough not to buy from Microsoft.
This is why programming languages don’t rush to support hyped new platform features without some combination of wide support and/or a very compelling use case in their core design or standard libraries.
Such paradigms need years, at least a decade, to percolate into the general programming culture. Microsoft (and I daresay companies in general) just doesn't have the stability to shepherd such changes.
Rather, it's the level of effort required to standardize, carry over, or reproduce a particular feature in the disparate environments we use.
Say Windows maintained that filesystem transactional feature. It'd be exposed in their C++ (?) API. What if you wanted to write your program in Python? What if you wanted to port it to Mac? Linux?
It just takes time for such platform features to percolate to the various environments that could use them.
I do not see how it follows. A smart developer will choose a database, not a file system, if data integrity is important. So it can be simply the case that the transactional API with a lot of its limitations were simply not flexible enough for people to bother.
Windows supports that since Windows Vista [1], and at least back then it was used by Windows Update and System Restore [2]. But programming languages usually only expose the lowest common denominator of file system operations in easy APIs, so approximately nobody uses it. Also, it's deprecated by now.
But maybe someone here has deeper insights in what went right and wrong with that implementation, because on the surface it looks like it would erradicate entire classes of security bugs if used correctly.
1: https://learn.microsoft.com/en-us/windows/win32/fileio/about...
2: https://web.archive.org/web/20080830093028/http://msdn.micro...