What are "transactional" file operations?

Question

I was browsing the Win32 API functions for file and directory management operations. I saw that some of those functions has their so called "transactional" counterparts.

Examples:
CreateDirectory and CreateDirectoryTransacted
RemoveDirectory and RemoveDirectoryTransacted
CreateFile and CreateFileTransacted
CopyFile and CopyFileTransacted

I read explanations of these transacted functions, the Wikipedia article Transactional NTFS and this MSDN Magazine page. But because of the heavy terminology (for me) in these pages, I didn't clearly understand these explanations. They all come to a common consensus that these functions are "atomic". But as far as I understand from the word "atom", it is a nucleus with spinning electrons around it...

Can you please explain me in basic and simple English sentences, what are the purposes and operations of these functions? Why and when would one prefer transacted version of an API function?

Answer 1

Why and when would one prefer transacted version of an API function?

There are a couple of scenarios given in the link I quoted above.

One of these is the use case of an installer application, which needs to copy/install several files to different locations and then maybe perform some updates to the registry. Before the installer runs the system can be considered consistent. Once the installer has done all its work, the software is completely installed and the system is again in a consistent state.

If, however, the computer crashes during the installation process it may not be trivial to determine which steps of the installation procedure have already been performed successfully before the crash and which have not. Transactional operations can give support in this situation by 'automatically' restoring the consistent system state as it was before the installer ran, if for any reason the installation fails in the process.

As Microsoft states, the transactional file system operations have never been adopted much by developers, which may serve as an indication that the functionality is not really needed for the vast majority of applications, or, that there are easier ways to achieve the desired result in an application-specific way, for which MS gives examples too.

Besides, the concept of "atomic" operations is present in different areas of software development, for instance in concurrent programming or in database management systems. See the Wikipedia article.

Answer 2

In short, a transaction (be it a file system, database or bank) will only be completed if no errors occurred in the process.

Using a non-transactional file system and API, say you have a file containing:

AAAA

Now you want to fill the file with all B's, but while doing so in the middle the power is lost and not all data is committed to the disk. Now you have an inconsistent state when you read the file back (after power returns):

BBAA

Remember FAT and scandisk?

Now with transactions, the file system basically first write the changes to a different location on the disk, and change the "file data location pointers" inodes towards the new location of the data only when finished, marking the space the old data occupied as 'available' again.

You don't need Transactional NTFS (TxF) for this, as 'standard' NTFS also promises to ensure consistency:

NTFS is a recoverable file system that guarantees the consistency of the volume by using standard transaction logging and recovery techniques. In the event of a system failure, NTFS runs a recovery procedure that accesses information stored in a transaction log file. The NTFS recovery procedure guarantees that the volume is restored to a consistent state. Transaction logging requires very little overhead.