Question

Target OS: Win2003

As posted in other SO questions about file operation atomicity, Win32 was simply not designed for transactions. Still I wonder whether file deletion could be non-atomic. After all, it is either get deleted or not. Or can a file remain in any other intermediate state on NTFS file system caused by a system crash or something else during deletion?

Was it helpful?

Solution

NTFS is a journaled file system. A journal is basically equivalent to a transaction log in a database. It'll ensure consistency and integrity of the file system structures like a database does for its tables. While File.Delete doesn't have any transactional code at the high level, NTFS does maintain transactional integrity at the filesystem level. This may not be true for other file system drivers.

OTHER TIPS

Old question, but if I could add to @Mehdrad's answer, from a slightly different standpoint...

On Windows, deleting a file often isn't even completely synchronous, and it isn't even a single operation. In that sense it's definitely not atomic.

If you look at tools like process monitor or look at MSFT documentation for writing a filesystem driver, you'll notice that to delete a file on Windows is a multi-step process. First you need a handle to the file. Then you set its disposition to "deleted". This puts the file in a state where it has a "delete pending". The file won't even be removed from view until the last handle to it is closed. When a file is in this state, new attempts to open the file will fail with STATUS_DELETE_PENDING. This status is more of a runtime thing -- if you pulled the plug or did a reboot the files won't stay in that state.

So, it may or may not be relevant to the way you're using deletes, but it's important to keep in mind that on Windows a delete won't necessary take effect right away and under concurrent access may lock further requests out of getting to the file.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top