Difference between revisions of "NKit/DiscFileSystem"
From WikiTemp, the GBAtemp wiki
Line 1: | Line 1: | ||
− | Once a Wii partition is decrypted and dehashed it is almost identical to a GameCube | + | Once a Wii partition is decrypted and dehashed it is almost identical to a GameCube disc. They key difference is that the file offsets in the fst.bin must be multiplied by 4 for the Wii. This is so that the Wii can address larger file systems that go beyond the 32 bit addressing that's used. |
== File System Rules == | == File System Rules == |
Revision as of 09:58, 6 September 2019
Once a Wii partition is decrypted and dehashed it is almost identical to a GameCube disc. They key difference is that the file offsets in the fst.bin must be multiplied by 4 for the Wii. This is so that the Wii can address larger file systems that go beyond the 32 bit addressing that's used.
File System Rules
- All files are at least 4 byte aligned
- The Gap between files can be 0 (always obeying the 4 byte alignment rule)
- If a file length is less than a multiple of 4 bytes it is padded to the 4 byte boundary with 0x0
- Non 0 length gaps are first padded to the next 4 byte boundary (1 to 3 bytes) then up to an additional 28 nulls are added if the gap is large enough
- Gaps are filled with junk starts after the trailing nulls
- NKit preserves files aligned at 32KiB that have a length that's a multiple of 32KiB. GameCube directly streamed audio files require this as do TGC files. NKit applies the same logic to Wii even though with the hashes the alignment is questionable, the dev kit appears to align these files
- Files are mostly pushed to the end of the filesystem
- The filesystem (in the largest partition for Wii) for non-service type discs always has a large gap. This gap does not have the trailing nulls following the previous file. The exact rules are unknown as to when this applies. Any gap larger than 0x40000 holds up for every image though. This was chosen as it's the size of 1 junk block
- Some files don't exist in the filesystem (Junk Files). The fst has them marked and the space is reserved on the disc, however the file is not there. If the missing file follows another file. The junk file will start with the trailing nulls from the previous file then junk filling any space. Typical files are debug and Windows type files like recycle bin etc. This is not common, even less so for Wii. One image has all the files from other regions listed in it that aren't in the image. 300mb of junk files. NKit sets the length of junk files to 0 in the fst and removes them. It is able to recreate them in restore.