Homebrew Proposed SD directory restructuring for homebrew

[TheCruel]

I've read people on gbatemp/IRC/reddit complaining about homebrew polluting their SD's root directory. This has become an issue because 3ds userland homebrew was initially designed to be in the 3dsx format, almost exclusively. However, many people do not want to use this format, and perhaps for good reasons which I won't describe here. And others simply will never be able to use this format because their homebrew isn't for userland.

Regardless, there have emerged many popular CIA-only homebrew and many homebrew apps that aren't in userland, and both of these types of homebrew face the problem of choosing where to save their data on the SD card. Most have resorted to merely making a directory/file on the SD root.

I propose the following simple restructuring:

sd:/3ds/apps/
This is similar to what the WiiU uses. This will be for 3dsx homebrew, essentially a renaming of sd:/3ds/ that currently exists. In the same fashion, all subdirectories will be 3dsx homebrew apps. And you can expect that removing sd:/3ds/apps/luma3ds, for example, will be removing a 3dsx luma launcher, and nothing more.

sd:/3ds/appdata/
This will be for data saved by homebrew, whether it be by 3dsx or CIA userland, or whether it by an arm9 bootloader needing to save a config file. It likewise would have subdirectories of homebrew names. The ideal behavior would be that removing directories here will not break their corresponding homebrew, and it will rather just deleting everything (data dumps, caches, config files, etc.) created by the homebrew. Of course, not all homebrew devs have made their homebrew self-contained to recreate config files and such, so therefore those files should be saved along with the app itself and not in this directory, otherwise deleting this subdirectory will make the app inoperable.

Benefits:

• Will give 3ds homebrew devs more flexibility when putting stuff in sd:/3ds/ without the need to pollute the directories used by HBL or other derivative launchers. Perhaps devs could also use sd:/3ds/cfw/ or sd:/3ds/arm9/ too, so people won't have rxTools/Luma3ds/Decrypt9/etc. directories in their SD root.
• Gives a proper separation of application and user data, similar to how PC environments operate.
• SD root directory would only need a few files/directories for 3ds homebrew purposes, making it nicer to use for other purposes as well.

Negatives:

• Requires a modification to HBL, albeit a simple one, using sd:/3ds/apps/ as the hb directory.
• 3dsx devs have come to expect CWD to provide their data space, and many aren't comfortable with changing to a fixed directory naming convention. This directory change won't break their work, but they'll simply not be compliant, having their user data mixed with app data against what would be expected.
• The current directory standard is so ubiquitous that changing it would break old tutorials (or confuse some end users). Some could perhaps consider it at a point of no return.

people want sd:/3ds to become sd:/3ds/apps so that CIA can put stuff in sd:/3ds/data or smth
sd:/3ds will still work

— smea (@smealum) July 2, 2016

I would like feedback, primarily from homebrew devs. Is there anything else to be considered?

 

[KapuDaKoopa]

I'm no dev, but I for one can say that this would be a nice change, as I hate all these folders cluttering up my root. Having all the homebrew in a 3ds folder, then the actual 3dsx homebrew in an apps folder INSIDE the 3ds folder would clean up the root a fair amount.
I support this 100% if someone attempts to make a hbl-mod
I guess while we're talking about someone making a hbl-mod custom theme support would be nice too but this isn't really ontopic now is is it sorry

 

[TurtleP]

I personally feel this is a good idea. Yeah it can break some homebrew projects, but it's a simple fix. I'm not sure how we could enforce it, but still I'd rather a clean SD (as many others would) than one cluttered with stuff. From what I can tell, however, 3dsx and cia save data tend to be something that does not differentiate unless you create extdata with ctrulib which is a pain to do. I think that it's just something that would need time to put into practice for many developers (even to update some homebrew applications for this).

 

[Billy Acuña]

@Shadowhand proposed something similar for non-userland homebrew, placing homebrew files/folders into "sd:/homebrew/3ds/".

 

[TurtleP]

@Billy Acuña we kind of already have a 3DS folder, so it just clutters it up by having another folder on root. This is a simple structure that could be followed for less confusion where to put everything. Example: retroarch. You could easily put the cores and everything inside of sdmc:/3DS/appdata/RetroArch/ which otherwise tends to confuse many people I think.

 

[a9lh-1user]

What if you dont need that (or whant it?).
The Shadownand thread already shows that the Dev's are in a internal discussion for that.
But imho i dont need that!
If the Dev's decide to do that the consequence will be that we are FORCED to use it i think.
And i dont like that.

But let's see in what direction it will go.

Again I dont like the idea of changing the FHS

 

[Ryccardo]

My opinion is that "3ds" was, in retrospect but probably also back then, a very poor choice for a folder chiefly dedicated to .3dsx!

 

[KapuDaKoopa]

My opinion is that "3ds" was, in retrospect but probably also back then, a very poor choice for a folder chiefly dedicated to .3dsx!

I agree
Something like homebrew or atleast hbl or 3dsx would have done the job better

 

[Ryccardo]

My second opinion is that, if devs were to implement format-specific features (ie: homebrew games compiled as cia/3ds should use romfs and the save system instead of loose files) this would be a non-issue for me and a good number of Others who don't use 3dsx anymore

 

[Damian666]

oh please, I hate the clutter

 

[TurtleP]

Personally, I'd think updating ctrulib to handle some of this would make things simpler. sdmc:/3DS/appdata/ would either have the title ID or application's name. Personally, name would be easier than title ID.

 

[Drakia]

I like this idea better than throwing yet another directory on the root like suggested elsewhere (/homebrew/3ds). Branching from the /3ds/ folder makes a lot of sense, and would keep the root clean instead of cluttering it more before anything gets better.

My second opinion is that, if devs were to implement format-specific features (ie: homebrew games compiled as cia/3ds should use romfs and the save system instead of loose files) this would be a non-issue for me and a good number of Others who don't use 3dsx anymore

RomFS for assets is fine, save files for anything is a bad idea. Users can't directly access a save file to, say, change a broken config, or copy a config for their friend.

 

[Sono]

If I remember correctly, the CWD is set by NH2.x on launching, so the apps wouldn't need to care about hardcoding their paths. I'm gonna test this out after I post this

Okay, to be fair, if you're using FSUSER functions, then you need to hardcode your paths, but if you were to use standard C functions, then you wouln't have this issue.

I wasn't really convinced about this issue, but I'll look into it, I think there should be a non-standard-C function to get the CWD, I'll look into it.

 

[Ryccardo]

RomFS for assets is fine, save files for anything is a bad idea. Users can't directly access a save file to, say, change a broken config, or copy a config for their friend.

Not my fault if people don't consider JKSV a cia killer app

 

[Drakia]

Not my fault if people don't consider JKSV a cia killer app

Being able to import/export a save file doesn't easily allow people to share portions of a config, hand-modify a config when there's no UI in the homebrew, etc.

 

[Deleted User]

I like this idea better than throwing yet another directory on the root like suggested elsewhere (/homebrew/3ds).

With that argument, wouldn't it then be logical to use the "Nintendo 3DS" directory that already exists instead of "3ds"?

 

[Ryccardo]

Being able to import/export a save file doesn't easily allow people to share portions of a config, hand-modify a config when there's no UI in the homebrew, etc.

Why not? Once a save is extracted, the individual files inside are perfectly accessible...

 

[Drakia]

With that argument, wouldn't it then be logical to use the "Nintendo 3DS" directory that already exists instead of "3ds"?

Because the community standard right now is to have a "3ds" folder, not to put homebrew in the "Nintendo 3DS" folder. This is discussion about an evolution of the current community-accepted "3ds" folder standard.

 

[Deleted User]

Because the community standard right now is to have a "3ds" folder, not to put homebrew in the "Nintendo 3DS" folder. This is discussion about an evolution of the current community-accepted "3ds" folder standard.

Except one of the main ideas behind it seems to be eliminating clutter in the SD root, and what better way to do that than have even fewer folders?

 

[Drakia]

Why not? Once a save is extracted, the individual files inside are perfectly accessible...

So, a save extracted with something like JKSM will just output a bunch of individual files? Also, what's the size limit on a savf? Will it be usable for something like a 2MB cache file?