对于从事服务端开发的技术人员而言，使用事务，尤其是控制分布式操作的事务是个至关重要的能力，如果某个环节“拿捏”不当，将在系统运维过程中用数十倍甚至数百倍的精力来解决。之前文件系统一直被作为一个典型的非事务性对象使用，也就是当数据库、队列、WCF等事务性对象在某种条件下回退的时候，中间操作过的文件系统也会保留痕迹；与之不同的是，TxF = NTFS + Tx，也就是文件系统也具有操作上的“All or Nothing”的事务性特征。在文章中，作者列举了这一文件系统的三个优势“提升应用稳定性”、“提升平台稳定性”和“增加创新机会”：借助TxF可以有效减少应用在异常情况下的“扫尾”工作，应用的可靠性交给操作系统保证。
在不使用TxF的时候，如果事务本身有多层嵌套，而且调用环境又是分布式环境，那么每处涉及文件访问的位置都需要“设防”。需要回退的话，如何通知远端文件系统本身就很困难（限于各种访问控制策略），加之错误本身很多时候就是因为连通性原因导致；在TxF环境下，应用不需要关心事务的层次，也不需要关心连通性故障。另外，使用TxF对于在线软件更新之类的应用特性也很有用，“半拉子”的情况最令人头疼，这种情况下应该考虑TxF的All or Nothing了。
但另外一个重要的地方是提供了一个“选项”——文件操作在异常处理时怎么办。实现方式上，TxF依赖于操作系统中KTM（Kernel Transaction Manager），而KTM可以与大家熟悉的DTC进行交互，相当于TxF可以间接地和任何支持DTC的技术进行事务协同。包括：
所有主流商用数据库平台、支持DTC分布式事务的开源数据库平台。
通过WS-AtomicTransaction协议保证的WebService调用。
声明为OleTransactionProtocol的WCF。
还有各主要商用队列产品。
再外延的话，由于DTC本身对XA-Transactions有支持，所以TxF甚至可以把操作Enlist到异构操作系统平台的事务管理产品中。
虽然TxF为开发人员开辟了一个非常广阔的调用空间，但它只是个“选项”，非事务性的文件系统在很多应用情境下还是非常必要的，诸如：
“业务操作日志”，必须保证它不会随着业务操作的回退而被“擦”掉。
还有就是长事务的情况，过多被打开而未关闭的文件将成为服务器的负载，尤其在宕机重启后，“扫尾”工作将成为系统的负担。
另外就是文件系统本身不适合多Writer的情况，每次一个TxF文件仅允许一个Writer写入（除非其它Writer与之在同一个事务内）。
全文链接：http://www.infoq.com/cn/news/2007/07/microsoft-file-system-txf
