Difference between revisions of "NKit/DiscFileSystem"
From WikiTemp, the GBAtemp wiki
(→File System Rules) |
|||
| (5 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| + | The following rules have been proven to be how the filesystem is made up for GameCube and Wii. | ||
| + | |||
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. | 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. | ||
| − | == | + | == FileSystem Rules == |
* All files are at least 4 byte aligned | * All files are at least 4 byte aligned | ||
* The gap between files can be 0 (always obeying the 4 byte alignment rule) | * The gap between files can be 0 (always obeying the 4 byte alignment rule) | ||
| Line 7: | Line 9: | ||
* 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 | * 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 | * 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 | + | * NKit preserves files aligned at 32KiB that have a length that's a multiple of 32KiB. GameCube directly streamed audio and .TGC files require this. 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 | * Files are mostly pushed to the end of the filesystem | ||
| − | * | + | * There is always a large gap between files. This applies to non-service discs, for Wii it's the largest partition. This gap does not start with the trailing nulls following the previous file. The exact rules are unknown as to when this applies. Any gap larger than 0x40000 works for every image. This was chosen as it's the size of 1 junk block, it may be less, more or have boundary limitations |
* 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 restore them | * 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 restore them | ||
* There are some GameCube images that appear to differ from the rules for some reason. Some also have some bytes in the junk that don't conform to the algorithm. NKit supports these with configuration entries | * There are some GameCube images that appear to differ from the rules for some reason. Some also have some bytes in the junk that don't conform to the algorithm. NKit supports these with configuration entries | ||
* The fst is always the first file in the file system | * The fst is always the first file in the file system | ||
* These rules start from the gap following the fst. This gap starts with the trailing nulls and junk | * These rules start from the gap following the fst. This gap starts with the trailing nulls and junk | ||
| + | |||
| + | == NKit FileSystem == | ||
| + | |||
| + | The NKit format filesystem uses the above rules to reencode gaps with a custom basic run length encoding (RLE) to compress them to 4 bytes in most cases. Scrubbed and non-junk is also supported. Where 32KiB alignments are preserved any padding is filled with 0x00. | ||
| + | |||
| + | The fst is updated to reflect the new file offsets. When restoring they are restored after all the gaps have been expanded. | ||
| + | |||
| + | The NKit Format is documented [[NKit/NKitFormat#FileSystem|here]]. | ||
Latest revision as of 18:51, 13 September 2019
The following rules have been proven to be how the filesystem is made up for GameCube and Wii.
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.
FileSystem 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 and .TGC files require this. 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
- There is always a large gap between files. This applies to non-service discs, for Wii it's the largest partition. This gap does not start with the trailing nulls following the previous file. The exact rules are unknown as to when this applies. Any gap larger than 0x40000 works for every image. This was chosen as it's the size of 1 junk block, it may be less, more or have boundary limitations
- 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 restore them
- There are some GameCube images that appear to differ from the rules for some reason. Some also have some bytes in the junk that don't conform to the algorithm. NKit supports these with configuration entries
- The fst is always the first file in the file system
- These rules start from the gap following the fst. This gap starts with the trailing nulls and junk
NKit FileSystem
The NKit format filesystem uses the above rules to reencode gaps with a custom basic run length encoding (RLE) to compress them to 4 bytes in most cases. Scrubbed and non-junk is also supported. Where 32KiB alignments are preserved any padding is filled with 0x00.
The fst is updated to reflect the new file offsets. When restoring they are restored after all the gaps have been expanded.
The NKit Format is documented here.
