On 13 Sep 2014, at 7:05pm, Roger Binns <rog...@rogerbinns.com> wrote:
> Ever hear of Windows and Transactional NTFS :-) > > http://msdn.microsoft.com/en-us/magazine/cc163388.aspx > > It turns out that adding transactions indiscriminately doesn't magically > make everything better and lots of thought does need to be applied to get > everything right. That leads to this: > > http://msdn.microsoft.com/en-us/library/windows/desktop/hh802690(v=vs.85).aspx I had heard of it but never encountered in the wild. It was a good idea which I don't think can be implemented on any variation of NTFS. For instance, a quote from your second reference: "You shouldn’t use TxF if you have a system that will have long-running transactions. The definition of "long-running" here is relative, however. A long-running transaction is any transaction that has been alive longer than many other transactions within the same log. This could mean a few seconds if there are thousands of transactions happening and lasting for very brief periods of time. On the other hand, a day or two might not be a long time if there are very few transactions happening in the system." So if I have a banking system that slowly does end-of-day processing, it can't be used on the same /volume/ that is being updated in real-time, even if they're working on completely different files. That's not much use. > Before Unix came along it was quite common for files to be structured, > managed by the operating system and to be record based with file apis > working that way. Unix turned files (and similar) into unstructured bags of > bytes. I would dispute that. Unix is not at fault here. Nor is Minix. Even the mainframes of the day did not support transactional file systems routinely. I can't think of any programming environment that 'expects' all file activity to be transactional. We haven't go there yet. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
