...
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 the table below.
...
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_FileWr() 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_FileWr() with or without file buffers.
...
.
...
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.
Table 12-1 Non-atomic API level operations
Journaling and device drivers
...