3 ms·
In a way, yes, definitely. But one does not get transactions. I would love a filesystem with transactional semantics. Surprisingly often, applications use some
by krylon 10y ago
In a way, yes, definitely.
But one does not get transactions. I would love a filesystem with transactional semantics. Surprisingly often, applications use some form of relational database not because their data is such a good fit for that model, but because they want/need transactions. In theory, one could roll their own transaction layer, after all, that's what RDBMSs do. But I have a hunch that getting transactions to work correctly without totally killing performance is not exactly trivial.
- vbezhenar 10y agoNTFS definitely have transactions. I'm not sure about other file systems.
- krylon 10y agoI had totally forgotten about that, you are right, NTFS does have a transaction API. I think I remember the API being marked as deprecated, though. Or is my memory playing tricks on me again?
- vbezhenar 10y agoYes, they deprecated it, claiming that developers didn't use it: https://msdn.microsoft.com/en-us/library/windows/desktop/hh802690(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/hh8...
- skissane 10y agoIMO, part of why developers didn't use it was the API design made using it too painful. They took most of the existing file APIs and added new *Transacted APIs alongside them, e.g. CreateFile begot CreateFileTransacted, etc. So to add filesystem transactions to your existing code, you had to change all the file API calls. I think, if they had made transactions work with the existing file API–such as by storing the hTransaction in thread-local storage, with an API to get/set the transaction association of the current thread, and having the existing non-transactional APIs behave transactionally in that case–it might have saw more adoption by developers.
- nthcolumn 10y ago...and alternate file streams.