To read all comments associated with this story, please click here.
And thank YOU for your explanation and your work. It looks like this is something all operating systems should have to implement patching, installing applications, updating websites, and so on.
I would LOVE an option in Windows Explorer to "transactionally" copy and move files and folders. Something like holding down a key while dragging. And a command line tool would be welcome.
Hopefully Linux will adopt something like this in the future. ZFS doesn't have this - a snapshot of an entile filesystem is completely different from a transaction about a part of the filesystem. Going back to an earlier snapshot means losing ALL new data, even the new data that you do not want to lose!
Filesystem transactions eh?
Ok, so what do you do when you have N transactions opened
racing at *some* common directories and files?
Do you block? If so, do you have dead-lock detection?
Please elaborate.
Do you fail-fast? If so, is first-come the champion?
Please elaborate.
And finally, what of applications not using tx-semantics? How do they fare against applications
tx'ing. Is each fs-op then considered a xaction?
If this is the case, what is the performance
impact on fs-op considering the overhead?
Thanks for replying on this site.
Will TxF be turned on by default for all file system ops? I hope it will. I hope you will include support for well-behaved legacy Win32 apps, so that early adopters see immediate benefits moving to Vista. This is similar to what Apple did with Carbon. Can you have a compatibility DLL that converts all but the lowest level file ops to use proper calls to TxF? Will ALL dotNet 2+ CLR apps use TxF under Vista?
C'mon, Microsoft is an incredibly brave company. Make everyone catch up to you guys again. More importantly, make things better for everyone without even letting them know it. There's an old adage stating that when something is done *right*, it can't be easily discerned that anything has been *done* at all. Most users won't notice TxF beyond the stupid errors and corrupton that are no longer happening, but everyone should *have* it.
-JM




Member since:
2005-12-04
I worked earlier in the year on Txf, and am now working on NTFS. Surendra (in the video) is my manager.
There seems to be a little confusion about a couple of points.
NTFS has always been journalled. Journalling is a very small transaction - a rename will either complete or fail, for example, you won't have two links to the same file, or no links, etc. When the volume is mounted, any half-done operations like this will be resolved. That is not new; ext3, zfs, plenty of filesystems do this.
TXF is a whole new kettle of fish. It provides for user-controlled, multiple updates, for longer periods of time. 'tummy' was exactly right with this:
Say:
copy fileb to filea
rename filea to filec
change contents of filec
create registry key HKLU/A/B
commit()
This is exactly correct. The kernel controls transactions; new applications can participate in the transaction as a Transactional Resource Manager, so that commit() can commit file changes, registry changes, or any 3rd party environment changes. The kernel understands transactions.
I can assure you, this is not a trivial undertaking.
I had a blog on this, which provides some old information; it's at http://blogs.msdn.com/because_we_can/. I'll try to update this with some more information when I get the chance.