242
edits
Changes
Jump to navigation
Jump to search
Line 15:
Line 15: − + + + Line 58:
Line 60: + + Line 121:
Line 125: − + Line 173:
Line 177: − + + Line 187:
Line 192: − + Line 224:
Line 229: + Line 543:
Line 549: − + + +
Embed diagrams
== Layout Variants ==
== Layout Variants ==
Four variants of the file system layout has been identified. A summary diagram can be found here: [https://github.com/wwylele/3ds-save-tool/raw/master/inner-fat.png]
Four variants of the file system layout has been identified. A summary diagram:
[[File:Inner-fat.png]]
=== Savegame, <code>duplicate data = true</code> ===
=== Savegame, <code>duplicate data = true</code> ===
** file entry table as well
** file entry table as well
** normal subfiles are NOT in the data region. They are in their DIFF containers instead.
** normal subfiles are NOT in the data region. They are in their DIFF containers instead.
The special file <code>00000000/00000001</code> is configured as external IVFC level 4 disabled, and all other device files are configured as it enabled.
=== Title database ===
=== Title database ===
| 0x30
| 0x30
| 4
| 4
| D of most recently mounted Extdata image
| ID of most recently mounted Extdata image
|-
|-
| 0x34
| 0x34
| Y + 0x30
| Y + 0x30
| 4
| 4
| File allocation table entry count
| File allocation table entry count
(excluding the leading 0th entry. See below)
|-
|-
| Y + 0x34
| Y + 0x34
| 4
| 4
| Data region block count
| Data region block count
(= number of file allocation table entries excluding the leading 0th entry. See below)
(= File allocation table entry count)
|-
|-
| Y + 0x44
| Y + 0x44
* For extdata, the maximum file/directory count are specified by the parameters of [[FS:CreateExtSaveData]]. The bucket count is likely calculated by the system.
* For extdata, the maximum file/directory count are specified by the parameters of [[FS:CreateExtSaveData]]. The bucket count is likely calculated by the system.
* Directory & file entry tables are allocated in the data region as if they are two normal files (except for savegame <code>duplicate data = false</code> layout). However, only continuous allocation has been observed, so directly reading block_count * block_size bytes from data_region + starting_block_index * block_size should be safe.
* Directory & file entry tables are allocated in the data region as if they are two normal files (except for savegame <code>duplicate data = false</code> layout). However, only continuous allocation has been observed, so directly reading block_count * block_size bytes from data_region + starting_block_index * block_size should be safe.
* For title database (except for ticket), the range specified for data region seems overflow the file end by 0x80 bytes, which is exactly the size of the pre header. This makes it as if the data region offset should be relative to the pre header instead of the BDRI header. However, further investigation on the directory/file table allocated inside the data region shows that the data region offset is indeed relative to the BDRI header. It might be a bug in 3DS that the title database files miss 0x80-byte space at the end.
== Directory Entry Table ==
== Directory Entry Table ==
All free blocks that are not allocated to any files also form a node chain in the allocation table. The head index of this "free chain" is recorded in <code>FAT[0].Index_V</code>. Other fields of <code>FAT[0]</code> are all zero
All free blocks that are not allocated to any files also form a node chain in the allocation table. The head index of this "free chain" is recorded in <code>FAT[0].Index_V</code>. Other fields of <code>FAT[0]</code> are all zero
Here is an example: [https://raw.githubusercontent.com/wwylele/3ds-save-tool/master/disa-fat.png]
Here is an example:
[[File:Disa-fat.png]]
For extdata, because only two "files" (directory and file entry tables) are allocated in the data region, and their size never changes once the extdata is created, they are guaranteed continuous in the data region, and the FAT degenerates to two big nodes. Therefore, instead of going through FAT, the offset and size of directory / file entry table can be found directly by offset = entry_table_starting block * data_region_block_size + data_region_offset and size = entry_table_block_count * data_region_block_size.
For extdata, because only two "files" (directory and file entry tables) are allocated in the data region, and their size never changes once the extdata is created, they are guaranteed continuous in the data region, and the FAT degenerates to two big nodes. Therefore, instead of going through FAT, the offset and size of directory / file entry table can be found directly by offset = entry_table_starting block * data_region_block_size + data_region_offset and size = entry_table_block_count * data_region_block_size.