Feedback exFAT still problematic for SD cards?

[BasedKiliK]

I ask because the reports I’ve read online have a mixed consensus on whether or not the issue is triggered by the use of homebrew, faulty/lesser quality SD cards, or a mixture of both (all due to Nintendo's crappy filesystem driver). I'd like to use the OoT Reloaded HD Texture pack for the Switch port of Ship of Harkinian, but the mod file is like 8 GBs, making FAT32 a no go there. I've seen videos of it working, but the folks who set up it must be using exFAT to get around the 4GB limit. I do use quite a bit of homebrew including Retroarch which apparently runs the largest risk of triggering corruption (probably due to how it writes data).

Is it still the same as ever, or are their methods in which it can still be used while avoiding corruption?

 

[Lamcza]

I ask because the reports I’ve read online have a mixed consensus on whether or not the issue is triggered by the use of homebrew, faulty/lesser quality SD cards, or a mixture of both (all due to Nintendo's crappy filesystem driver). I'd like to use the OoT Reloaded HD Texture pack for the Switch port of Ship of Harkinian, but the mod file is like 8 GBs, making FAT32 a no go there. I've seen videos of it working, but the folks who set up it must be using exFAT to get around the 4GB limit. I do use quite a bit of homebrew including Retroarch which apparently runs the largest risk of triggering corruption (probably due to how it writes data).

Is it still the same as ever, or are their methods in which it can still be used while avoiding corruption?

i get corruption a month ago on fat32 it was becouse of not even "broken" sd card reader
but i lerned two pretty neat symptoms of sd card reader problems so not bad next time i will be rady

back to your question idk man i would not risk exfat i have 512 gb sd it is so painfull to set it up after corruption and now iam upgrading to 1tb sooo xD

maybe you can install that game on another sd card to avoid any complication with your main sd, just dont swap it too often and not in hekate becouse it is not rlly supported i guess?

but if you have some smaller sd like 128 i guess you can test it yourself why not

 

[Ryab]

I've always used Fat32 since the beginning. I've never had a single issue with it. The only instanced where you would really have a file larger is with games being installed. But there are many methods around that.

 

[Lamcza]

I've always used Fat32 since the beginning. I've never had a single issue with it. The only instanced where you would really have a file larger is with games being installed. But there are many methods around that.

i mean he has another issue if iam getting it correctly he want to use mod that has files larger then 4gb so if he cant unpack it somehow and make it work he would probbaly need that exfat

 

[Ryab]

i mean he has another issue if iam getting it correctly he want to use mod that has files larger then 4gb so if he cant unpack it somehow and make it work he would probbaly need that exfat

That sounds like an extreme fault on the developer of the mod.

 

[Delerious]

The way I understand it, it's not 100% to do with Nintendo's drivers, but largely with how exFAT works, especially when it comes to writing and allocating data. exFAT was more of a problem in earlier days of Switch homebrew development, because a lot of homebrew, and Atmosphere itself, was pretty unstable. Because of that, programs would crash, and people would often have to force their Switch to power off. If an app was ever writing data at the time, corruption would occur, and this was perpetuated by apps that were constantly writing data. Nowadays, those problems are less common, so people don't seem to be experiencing quite as many problems with exFAT as they were back then. As for the FAT32 recommendation that devs were giving people, a lot of it was because they didn't want too deal with the headache of half their users complaining to them about how their app corrupted their data.

For the most part, as long as you're shutting down your Switch properly with all apps closed BEFORE shutting it down, and closing your apps properly (i.e. when they're NOT running a process that's writing data), you shouldn't have any issues. Also, make sure you're using the most stable builds for your favorite homebrew apps, and that they're okay to work with your current version of Atmosphere. If an app crashes on you regularly, don't use it, even if you're on FAT32.

Another thing to add with exFAT, is make sure you're using the correct allocation size when you format it, and that you're not using a card that's known to cause issues.

 

[hippy dave]

Yes exfat is still a problem, and will continue to be until Atmosphere reimplements the FS module and fixes the bug(s). Stick to fat32.

The Switch can use files bigger than 4GB on fat32 by splitting them in a folder and setting an attribute. IIRC you can use DBI's MTP server to copy files to the Switch and it should handle this automatically. I believe that should work transparently with homebrew in general, including SoH.

 

[masagrator]

Nowadays, those problems are less common, so people don't seem to be experiencing quite as many problems with exFAT as they were back then.

It's less common because people are now more aware of exfat issues than before. This was never fixed for homebrew scene as issue persists to this day. There is no other way to get around it for now than homebrew CRCing saved data on sdcard to check if data was written properly. And this slows down saving data for every failed CRC check + currently there is no way to know from HOS if sdcard is using exfat or not, so we can't use that method only for exfat cards. So for homebrew where data save speed matters it's not a viable choice.

I have homebrew that is patching FF VIII romfs to get translation mod installed. 3/5 attempts on exfat cards were causing my CRC checks to fail. With FAT32 no issues whatsoever.

Post automatically merged: Sep 8, 2023

The Switch can use files bigger than 4GB on fat32 by splitting them in a folder and setting an attribute.

or by going to libnx -

/// Uses \ref fsFsQueryEntry to set the archive bit on the specified absolute directory path.
/// This will cause HOS to treat the directory as if it were a file containing the directory's concatenated contents.
Result fsFsSetConcatenationFileAttribute(FsFileSystem* fs, const char *path);

So putting >4GB files on fat32 was never an issue for homebrew.

 

[Delerious]

It's less common because people are now more aware of exfat issues than before. This was never fixed for homebrew scene as issue persists to this day. There is no other way to get around it for now than homebrew CRCing saved data on sdcard to check if data was written properly. And this slows down saving data for every failed CRC check + currently there is no way to know from HOS if sdcard is using exfat or not, so we can't use that method only for exfat cards. So for homebrew where data save speed matters it's not a viable choice.

I have homebrew that is patching FF VIII romfs to get translation mod installed. 3/5 attempts on exfat cards were causing my CRC checks to fail. With FAT32 no issues whatsoever.

Post automatically merged: Sep 8, 2023

Ah, okay. I had read a few posts in <no> that suggested otherwise. The annoying thing about reading information regarding such issues is that even when it comes from developers, much of it can be skewed. It's kind of gone back and forth between "It's an exFAT issue" and "It's a Nintendo driver issue."

Likewise though, I've yet to have any issues with exFAT, myself, and I run mods on a few of my games and use RetroArch and PPSSPP for emulation. So far, I've not had issues (knock on wood), but I'm also careful when it comes to how I'm closing my software, and I try not to use too many mods, either. That said too, part of me has been curious as to whether it's entirely a driver issue, because there are many of us who, thus far, have had no issues, and even among those that do, some experience them fewer than others. Does every Switch model - specifically hackable ones - have the exact same reader/controller with the exact same iteration?

 

[ghjfdtg]

It's both a problem with the design of exFAT and Nintendos driver. exFAT only has a single file allocation table. If entries get lost the file is lost for good. That is paired with the driver not handling file entries well when file handles don't get closed properly or on crashes/poweroff.

I myself thought exFAT can't be that bad and tried it. The fs was corrupted first day i modded my Switch. Random files and titles disappeared out of nowhere. With FAT32 no issue.

 

[Ryab]

Exfat also has extremely bad fragmentation issues.

 

[TomSwitch]

As long as you are ready for the SD card content to be lost there is no problem using exFat, many are ready to do that and did when they just want to have their file bigger. It's more like smoking, it's not like you smoke you die, some lives to more than 100 years old. I would still advise people to not smoke just like I advise people to not use exFat.

 

[urherenow]

And as for the dev opinions (ok, at least 1), the #1 recommended way to format your sd is through NYX. exFAT is not an option there.

 

[Ligeia]

I used to use exFAT and got problems with games randomly being corrupted and deleted. At some point 90% of my games got erased.

I reformatted to FAT32 and everything's been fine ever since.

 

[BasedKiliK]

Yes exfat is still a problem, and will continue to be until Atmosphere reimplements the FS module and fixes the bug(s). Stick to fat32.

The Switch can use files bigger than 4GB on fat32 by splitting them in a folder and setting an attribute. IIRC you can use DBI's MTP server to copy files to the Switch and it should handle this automatically. I believe that should work transparently with homebrew in general, including SoH.

Now that I've gotten around to it, I did exactly this, and it worked splendidly. Thank you!

 

[Twiggs4625]

Yes exfat is still a problem, and will continue to be until Atmosphere reimplements the FS module and fixes the bug(s). Stick to fat32.

The Switch can use files bigger than 4GB on fat32 by splitting them in a folder and setting an attribute. IIRC you can use DBI's MTP server to copy files to the Switch and it should handle this automatically. I believe that should work transparently with homebrew in general, including SoH.

Can you install and play games that I rip that are larger than 4GB on the SD Card if it is FAT32? I want to be able to install all my ripped carts to the SD Card if possible.

 

[AlexMCS]

Can you install and play games that I rip that are larger than 4GB on the SD Card if it is FAT32? I want to be able to install all my ripped carts to the SD Card if possible.

Yes you can, just split the file in 4GB chunks, save it in a folder, and set the archive bit on it using any homebrew file manager, DBI, Goldleaf etc.

I use a python program for splitting, some implementation, as mentioned above (DBI's MTP) do it automatically for you.

 

[thesjaakspoiler]

I managed to wreck an exFat SD card in the official firmware.
My game bought from the eshop crashed and all I could to was forcefully turn off the Switch.
And the contents of the SD card was wrecked in the process.

 

[Tokiwa]

Can you install and play games that I rip that are larger than 4GB on the SD Card if it is FAT32? I want to be able to install all my ripped carts to the SD Card if possible.

If you're just installing games then use usb install, DBI can install via mtp and it's pretty easy and painless. It also supports installing via external storage like usb hdd. The game size doesn't matter when installing that way.

 

[Twiggs4625]

Yes you can, just split the file in 4GB chunks, save it in a folder, and set the archive bit on it using any homebrew file manager, DBI, Goldleaf etc.

I use a python program for splitting, some implementation, as mentioned above (DBI's MTP) do it automatically for you.

If you're just installing games then use usb install, DBI can install via mtp and it's pretty easy and painless. It also supports installing via external storage like usb hdd. The game size doesn't matter when installing that way.

Thank you. I appreciate the feedback.