SettingsHandler: Always decode the whole settings.txt file #8680
Conversation
|
Decrypting junk at the end doesn't sound perfect to me, but I can't think of a better way... I wonder how actual Wii software handles it? I'm fine with merging this if nobody can think of a "cleaner" solution. |
|
Maybe the Wii is just assuming that the file has a certain amount of lines / entries? We could do that as well, but that might cause other issues. Decrypting junk, while not being an ideal solution, should at least not cause problems. |
|
As long as we're not unlucky enough that the junk happens to decode into something valid, that is. But the chances of that happening are much much smaller than the chance of the valid encrypted data containing a null byte, at least. |
|
The junk decrypting into something valid wouldn't be a problem either. |
|
I just tested three different NAND backups again (one of which did work before, two of which did not work before due to the null byte) and all of them do import properly with the proper serial number. |
|
This PR is just waiting for someone else to review. I was planning to merge it in a day or two from now if nobody does. |
Fixes https://bugs.dolphin-emu.org/issues/12019
Related to https://bugs.dolphin-emu.org/issues/11930 and to #8673 and #8670
The encrypted settings.txt can contain nullbytes - it's a binary file. The old code assumed a null byte means "end of file". That's not the case - for some files, the current code stops parsing in the middle of the file. (That took me a while to figure out ...)
This approach decrypts the junk data at the end of the file, too, but because the valid data always ends with a newline, all the junk ends up on new line(s) at the end, meaning, the parsing code should just ignore that junk. The decrypted data unfortunately doesn't end with a null byte, and we don't know the length of the decrypted data, so I don't see any way to detect and remove that junk data.
Please merge this prior to #8673.