...
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 Appendix 12, “How Journaling Works” 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 12-1the table below.
API level operation | API level function | Possible interruption side effects |
Entry copy |
| The destination file size could end up being less than the source file size. |
File write (data appending) |
| The file size could be changed to any value between the original file size and the new file size. |
File write (data overwriting) |
| If existing data contained in a file is overwritten with new data, data at overwritten locations could end up corrupted. |
File extension |
| 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. |
...