A NAND backup can recover you from 99.9% of all problems. The only things it can't save you from is from are burnt fuses and a fried battery.So is there a way to recover from a bad .nsp? Or protect ourself from it even happening?
We can't tell you, and you aren't allowed to ask eitherWhere do you guys get your switch games?
The names have to do with how they're obtained but they have zero bearing on the functionality of the .NSP file. You can also convert any .XCI file into .NSP.Most NSP files I've been downloading are named using the key and version, but others don't have it.
Is it mandatory for NSP files to have a name like "Mario Tennis Aces [0100bde00862a000][v0].nsp" to function?? What about DLC/updates?
Can I name my NSP files just "Mario Tennis Aces.nsp" and "Mario Tennis Aces [update].nsp" for example?
I also have "Yonder The Cloud Catcher Chronicles [0100534009FF2000][v0].nsp" and those numbers aren't a valid key according to the nswdb site (can't try it since my SX OS Pro arrives next week). Is the file OK or should I download another one with a correct key number?
Bonus question: can I convert trimmed XCI to NSP or do I need the raw files??
This thread has an idea of a list that gets updated when you install certain .NSP files.
You can simply toggle AutoRCM off during the installation process which I'd only recommend if you aren't changing your firmware version (meaning you're just adding exFAT support to your current firmware). And currently, only ReiNX supports .XCI files being installed due to a special patch that only works with ReiNX. There are currently no plans to add such a patch to Atmosphere. Lastly, I use both for testing purposes but I personally prefer an exFAT formatted SD card because I'm lazy. I had corruption happen to me once but it was expected.
It can mess up your ticket database making it unable for you to play most, if not all, your games which is a functional brick since it takes away the primary function of the console.
You can remove the SD card while the console is turned off or in RCM.
Hypothetically, it can be solved by rewriting the filesystem drivers the Switch uses but as you can imagine, that is not easy. Its possible ReSwitched made attempt to do so with Atmosphere since its designed to replace Horizon but for right now, exFAT is a ticking time bomb on the Switch when it comes to corruption.
If you ever lose the license and the license-request files, you will have to buy a new license.
Removing the SD card while in sleep mode or active usage causes the console to reboot. It can only be removed in RCM or while it is turned off.Can I remove the SD card while the Switch is in sleep mode without messing anything up? Obviously I'd put it back in the Switch prior to waking the Switch up.
Hypothetically, it can be solved by rewriting the filesystem drivers the Switch uses but as you can imagine, that is not easy. Its possible ReSwitched made attempt to do so with Atmosphere since its designed to replace Horizon but for right now, exFAT is a ticking time bomb on the Switch when it comes to corruption.
It doesn't have to do with the way a program is launched; it has to do with how programs handle files on the console. If Tinfoil crashes while installing a .NSP file, it doesn't matter if it was launched as an .NRO or .NSP; the cause lies in how Tinfoil is processing the files on the SD card based on how Horizon operates.When you say ticking time bomb, is it a time bomb for everyone including non-CFW users? Is it a time bomb for CFW users that only use it to play Switch games?
Edit: I see it's a homebrew only problem, so I suppose Nintendo has no incentive to fix it, right?
Does using Tinfoil NRO run the risk of corruption? Can I mitigate this by using an NSP launcher? Does using an NSP launcher for RetroArch mitigate the problem?
It doesn't have to do with the way a program is launched; it has to do with how programs handle files on the console. If Tinfoil crashes while installing a .NSP file, it doesn't matter if it was launched as an .NRO or .NSP; the cause lies in how Tinfoil is processing the files on the SD card based on how Horizon operates.
Any unstable homebrew is liable to corrupt the SD card. For example, kezplez-nx is a very finicky homebrew application that needs file in certain places and named in a certain way. If it fails during the process, it will corrupt the SD card because that failure interrupts kezplez-nx reading the SD card. Another example was the ReiNX toolkit which caused corruption due to people not exiting it properly (by using the Home menu rather than the Exit button). Basically, the more stable and appropriately used a homebrew app is, the less of a chance of corruption.Is corruption a common problem for Tinfoil, or is it more common with RetroArch?
Any unstable homebrew is liable to corrupt the SD card. For example, kezplez-nx is a very finicky homebrew application that needs file in certain places and named in a certain way. If it fails during the process, it will corrupt the SD card because that failure interrupts kezplez-nx reading the SD card. Another example was the ReiNX toolkit which caused corruption due to people not exiting it properly (by using the Home menu rather than the Exit button). Basically, the more stable and appropriately used a homebrew app is, the less of a chance of corruption.
Never heard of anyone experiencing corruption when using Tinfoil. Goes to show how great of a developer Adubbz was.Is Tinfoil pretty safe generally?