...
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. 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
...