NKit/DiscFileSystem - Revision history

Nanook at 18:51, 13 September 2019

2019-09-13T18:51:42Z

← Older revision		Revision as of 18:51, 13 September 2019
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.

Nanook: /* NKit FileSystem */

2019-09-09T13:48:09Z

NKit FileSystem

← Older revision		Revision as of 13:48, 9 September 2019
Line 21:		Line 21:
	The fst is updated to reflect the new file offsets. When restoring they are restored after all the gaps have been expanded.		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 ~~<well, not yet>~~.		The NKit Format is documented [[NKit/NKitFormat#FileSystem\|here]].

Nanook at 12:35, 6 September 2019

2019-09-06T12:35:50Z

← Older revision		Revision as of 12:35, 6 September 2019
Line 1:		Line 1:
	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.

	== ~~File System~~ Rules ==		== 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)

Nanook at 12:34, 6 September 2019

2019-09-06T12:34:52Z

← Older revision		Revision as of 12:34, 6 September 2019
Line 14:		Line 14:
	* 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 here <well, not yet>.

Nanook: /* File System Rules */

2019-09-06T10:40:29Z

File System Rules

← Older revision		Revision as of 10:40, 6 September 2019
Line 7:		Line 7:
	* 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 ~~files~~ and .TGC 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		* 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		* 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

Nanook: /* File System Rules */

2019-09-06T10:13:30Z

File System Rules

← Older revision		Revision as of 10:13, 6 September 2019
Line 9:		Line 9:
	* NKit preserves files aligned at 32KiB that have a length that's a multiple of 32KiB. GameCube directly streamed audio files and .TGC 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		* NKit preserves files aligned at 32KiB that have a length that's a multiple of 32KiB. GameCube directly streamed audio files and .TGC 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
	* ~~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		* 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

Nanook: /* File System Rules */

2019-09-06T10:08:06Z

File System Rules

← Older revision		Revision as of 10:08, 6 September 2019
Line 7:		Line 7:
	* 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 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		* NKit preserves files aligned at 32KiB that have a length that's a multiple of 32KiB. GameCube directly streamed audio files and .TGC 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
	* 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		* 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~~		* 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		* 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

Nanook: /* File System Rules */

2019-09-06T10:03:54Z

File System Rules

← Older revision		Revision as of 10:03, 6 September 2019
Line 11:		Line 11:
	* 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		* 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		* 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
			* 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

Nanook at 10:02, 6 September 2019

2019-09-06T10:02:58Z

← Older revision		Revision as of 10:02, 6 September 2019
Line 3:		Line 3:
	== File System Rules ==		== File System 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)
	* If a file length is less than a multiple of 4 bytes it is padded to the 4 byte boundary with 0x0		* 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		* 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
Line 10:		Line 10:
	* Files are mostly pushed to the end of the filesystem		* 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		* 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.		* 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
			* These rules start from the gap following the fst. This gap starts with the trailing nulls and junk

Nanook at 09:58, 6 September 2019

2019-09-06T09:58:27Z

← Older revision		Revision as of 09:58, 6 September 2019
Line 1:		Line 1:
	Once a Wii partition is decrypted and dehashed it is almost identical to a GameCube ~~discs~~. They key difference is that the file offsets in the fst.bin must be multiplied by ~~for~~ 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.

	== File System Rules ==		== File System Rules ==