Share via

Transactional NTFS

  • Article

Applies To: Windows Server 2008

Transactional NTFS file system and the Transactional Registry, the kernel transactional technology in the Windows Server® 2008 operating system, have been enhanced to coordinate their work through transactions. Because transactions are necessary to preserve data integrity and handle error conditions reliably, you can use Transactional NTFS to develop robust solutions on systems running Windows Server 2008.

What does Transactional NTFS do?

Transactional NTFS allows file operations on an NTFS file system volume to be performed transactionally. It provides support for full atomic, consistent, isolated, and durable (ACID) semantics for transactions. For example, you can group together sets of file and registry operations with a transaction so that all of them succeed or none of them succeed. While the transaction is active, the changes are not visible to readers outside of the transaction. Even if the system fails, work that has started to commit is written to the disk, and incomplete transactional work is rolled back.

Transactions used with the file system or registry can be coordinated with any other transactional resource, such as SQL Server or Message Queuing (also known as MSMQ). The command line has been extended with the Transact command to allow simple command-line scripting using transactions.

Who will be interested in this feature?

Transactional NTFS is intended for use by IT professionals who need a way to ensure that certain file operations are completed without interruption or possible error.

What new functionality does this feature provide?

Transactional NTFS provides the following functionality:

  • Transactional NTFS integrates with COM+. COM+ is extended to use the Windows NT APIs to automatically bind the Windows NT equivalent of the COM+ transaction with the thread on which it schedules an object. Therefore, applications that use the COM+ transaction model can simply specify an additional object property that indicates transactional file access intent. Legacy applications using the COM+ model that do not specify this additional property will access files without using Transactional NTFS.

  • Each NTFS volume is a resource manager. A transaction that spans multiple volumes is coordinated by the Kernel Transaction Manager (KTM). Consistent with the Windows NT architecture, this feature supports Windows NT volume independent recovery. For example, a system can be restarted with some of the volumes "missing" without affecting the recovery on the other volumes.

  • A file handle can be closed before the transaction commits or aborts. The commit or abort is typically performed by an entirely different thread than the one that performed the file work. Transacted handles are expected to be used only while the transaction is active. The system marks them as unusable after the transaction ends. Their attempt to modify the file fails, and the system presents an error message.

  • You can view a file as a unit of storage. Partial updates and complete file overwrites are supported. It is not expected that multiple transactions concurrently modify parts of the file—this is not supported.

  • Memory mapped I/O works transparently and consistently with the regular file I/O. The only additional work needed is for the application to flush and close an opened section before committing a transaction. Failure to do this will result in including partial changes in the transaction.

  • Accessing a remote file using SMB Service and Web-Based Distributed Authoring and Versioning (WebDAV) is supported transparently. The transaction context is carried to the remote node by the system automatically. The transaction itself gets distributed and coordinated for commit or abort. This should allow applications to be distributed across the multiple nodes with a great degree of flexibility. This is powerful because it transacts network file transfers, which emulates a form of transacted messaging.

  • Each volume contains its own log. The common log format is used for providing recovery and aborts. The common log format also builds a common Windows transaction-logging facility for use by other stores.

Additional references

For information about other features in File Services, see the File Services Role topic.