Page Comparison

...

While the journaling system does provide top-level FAT layer operation atomicity, it does not necessarily provide API-level operation atomicity. Most of the time, one API-level file system operation will result in a single top-level FAT operation being performed (see How Journaling Works). In that case, the API-level operation is guaranteed to be atomic. For instance, a call to FSEntry_Rename() will result in a single FAT rename operation being performed (assuming that renaming is not cross-volume). Therefore, the API-level rename operation is guaranteed to be atomic. On the other hand, a call to FSFile_Truncate() will likely result in many successive top-level FAT operations being performed. Therefore, the API-level truncate operation is not guaranteed to be atomic. Non-atomic API level operations, along with the possible interruption side effects, are listed in Table - Non-atomic API level operations.

Panel

borderWidth	0
title	Table - Non-atomic API level operations

API level operation	API level function	Possible interruption side effects
Entry copy	`FSEntry_Copy()` or FSEntry_Rename() with the destination being on a different volume than source.	The destination file size could end up being less than the source file size.
File write (data appending)	`FSFile_Wr()` with file buffers enabled.	The file size could be changed to any value between the original file size and the new file size.
File write (data overwriting)	`FSFile_Wr()` with or without file buffers.	If existing data contained in a file is overwritten with new data, data at overwritten locations could end up corrupted.
File extension	`FSFile_Truncate()` or `FSFile_PosSet()` with position set beyond file size.	The file size could be changed to any value between the original file size and the new file size. Also, unwritten file space could contain uninitialized on-disk data.

Journaling and device drivers

...

Versions Compared

Old Version 8

New Version Current

Key

Journaling and device drivers