File Name collision doesn't raise an error; this will hide chunks that share the same name and fourCC code; which is common for chunks which store their name inside the chunk data instead of the header.
The current chunkyFS solution also fails on chunkies with more than 100+ chunks; SGB's i believer were the big offender.
Original Issue
This issue lies in Relic-Tool-Chunky-Core
Unlike SGA archives, which IS a filesystem packed into a single file. Chunky isn't a filesystem; but a tree. Chunk names aren't unique even when appending an extensions via a chunk's four character code (which is required since most chunks lack any name).
This problem could be solved in several different ways, if we assume that chunk names are purely for human readability.
Appending Chunk Index
A quick solution, no matter what, two chunks can share the same 'index' (when being read). This allows the ChunkyFS to be created, but will pollute all names, even those that don't get duplicated. Assuming we prioritize the ChunkyFS name over the name stored in metadata, this also means unpacking/repacking assets will create more disgusting names.
Windows Approach, Append 'N' to File Name
When constructing the ChunkyFS, if a collision occurs, append a number to it. This requires us to repeatedly try to create the path with increasing N until we succeed.
We'd likely want to limit this to something like 100 tries. This also runs the risk of creating situations where "fileName-2.ext" -> "fileName-2-2.ext" -> "fileName-2-2-2.ext"
There are certainly other options, but these are the two I'm currently considering.
The offending files are WHM debris chunkies; which contain a LOT of MSLC chunks, some of which may be actual duplicates.
Update 10/15/2022
File Name collision doesn't raise an error; this will hide chunks that share the same name and fourCC code; which is common for chunks which store their name inside the chunk data instead of the header.
The current chunkyFS solution also fails on chunkies with more than 100+ chunks; SGB's i believer were the big offender.
Original Issue
This issue lies in Relic-Tool-Chunky-Core
Unlike SGA archives, which IS a filesystem packed into a single file. Chunky isn't a filesystem; but a tree. Chunk names aren't unique even when appending an extensions via a chunk's four character code (which is required since most chunks lack any name).
This problem could be solved in several different ways, if we assume that chunk names are purely for human readability.
Appending Chunk Index
A quick solution, no matter what, two chunks can share the same 'index' (when being read). This allows the ChunkyFS to be created, but will pollute all names, even those that don't get duplicated. Assuming we prioritize the ChunkyFS name over the name stored in metadata, this also means unpacking/repacking assets will create more disgusting names.
Windows Approach, Append 'N' to File Name
When constructing the ChunkyFS, if a collision occurs, append a number to it. This requires us to repeatedly try to create the path with increasing N until we succeed. We'd likely want to limit this to something like 100 tries. This also runs the risk of creating situations where "fileName-2.ext" -> "fileName-2-2.ext" -> "fileName-2-2-2.ext"
There are certainly other options, but these are the two I'm currently considering.
The offending files are WHM debris chunkies; which contain a LOT of MSLC chunks, some of which may be actual duplicates.