Homebrew Proposed SD directory restructuring for homebrew

[chaoskagami]

@chaoskagami You get an application and it has a 3dsx and a folder, where else do you think it would go? Data. Sorry if this reply sounds rude, but I'm not trying to be.

Nah, it's fine. I should have used more emotes, honestly. Came across a little rude myself. Sorry.

I'm probably overcomplicating this.

 

[TurtleP]

Either way it's fine, @chaoskagami . Your opinion and others are welcome since we're still trying to get everyone on board with one universal schema for the scene .

 

[Futurdreamz]

I'm butting in late so I don't know what has been said, but I agree with branching off from the 3ds/ folder. It would make it easier to keep track of everything, and prevent accidental deletions of folders because you do not recognize the name.

But I recommend this layout, if possible:
3ds/apps/ - which will contain the app and the resources required for it to function
3ds/resources/ - contains optional resources that are app specific, such as themes. The resources should ideally be contained in a folder with the app's name, so that if you want to delete the app you can find all resources used by it.
3ds/config/ - contains all configuration settings for all apps, so that the app can be replaced or upgraded without losing your configuration.
3ds/data/ - contains all data that is mostly app-agnostic (such as roms and their saves).

 

[TurtleP]

@Futurdreamz not to burst your bubble, but here's issues:

1) Resources and data are practically the same. They can be /data/ to be kept as one short named folder
2) Config is useless since /data/ handles all application information (excluding Custom Firmware)
3) Where would you put a custom firmware? That's why I had suggested /boot/ for those.

 

[Shadowhand]

I hate to say this, but this is all a topic with no correct answer. *sigh* We all need to just pick something and run with it.

I propose /homebrew/3ds/
People are like "BUT HBL WOULDN'T WORK THENW!?!=!!?!?!!1!!". Who said HBL wouldn't be updated?

What I envisioned was:

/homebrew/
  /3ds/
    /luma/
    /saltfw/
    /hbchannel/ (formerly known as /3ds/ at the root of SD)
    /JKSV/
    /pkhbank/
    /whatever else/
    /boot.bin
    /bootmgr.bin
    /bootmgr.ini
  /wiiu/ (if they really want to)

 

[Joel16]

This guy gets it. I think you have the best suggestion yet, personally.

Why actually do we have this weird console-named root path clutter? Is it dating back to the PSP where that was sony's doing, and somehow carried over into other scenes, or...? Eh.

Either way, the PSP was better organized than the 3DS folder. Reminder of sony/cfw layout:

ms0:/
  PSP/
    GAME/
      Game_Folder/
        ..
    GAME150/
    GAME3XX/
    THEME/
    SAVEDATA/
    COMMON/
    SYSTEM/

This is an official layout and it's still better than the current mess.

This is what I stated a few pages back. The PSP layout seems well organized to me (at least compared to what we have currently). Having a 3Ds directory and subdirectories for homebrew, themes, data and such should suffice.

I also agree with Cruel's layout. Even though how I said just renaming the folders with the same concepts wouldn't change much, it still is noob-friendly.

/3DS/
    apps/
    appdata/
    boot/

We can remove logs/ unless a cfw dev or other devs agree to have that anyways. Most users won't even need that folder, but if you do have crashes it's nice to know where they would be instead of on root.

^
This is what I mean haha

 

[chaoskagami]

I propose /homebrew/3ds/
People are like "BUT HBL WOULDN'T WORK THENW!?!=!!?!?!!1!!". Who said HBL wouldn't be updated?

What I envisioned was:

/homebrew/
  /3ds/
    /luma/
    /saltfw/
    /hbchannel/ (formerly known as /3ds/ at the root of SD)
    /JKSV/
    /pkhbank/
    /whatever else/
    /boot.bin
    /bootmgr.bin
    /bootmgr.ini
  /wiiu/ (if they really want to)

The problem is certain closed source homebrew which have hardcoded paths to /3ds/whatever. HBL is easy to update. It's the applications which were relying on broken behavior in the first place.

Structure-wise? That's A-OK with me. As long as everyone can agree on a standard and enforce it on the outliers by making changes to HBL, then whatever.

 

[Shadowhand]

The problem is certain closed source homebrew which have hardcoded paths to /3ds/whatever. HBL is easy to update. It's the applications which were relying on broken behavior in the first place.

Structure-wise? That's A-OK with me. As long as everyone can agree on a standard and enforce it on the outliers by making changes to HBL, then whatever.

Certain close sourced homebrew devs should be kind enough to update their paths. We can't give up on having a structure because a small handful of people refuse to work with it.

 

[chaoskagami]

Certain close sourced homebrew devs should be kind enough to update their paths. We can't give up on having a structure because a small handful of people refuse to work with it.

I agree 100%. If they won't switch to the new standard (whatever it may be) that's their loss. Let their code be RE'd and fixed up for all I care.

The point is that we're going to break backwards compatibility here, inevitably. Users need to prepare for that.

 

[a9lh-1user]

If there comes a new standard the only way most users will notice it will be if their system isn't running as they would like it or if the great Plailect guide get an update!
I dont thing that this thread or many others with this topic are read by many people.
I dont even thing that many users update their CFW if they have finished a guide for A9LH (or any other way of CFW!) until it isn't working anymore!
(Most users dont see the potential that comes with a CFW ...... they see only free gaming!)
My question would be : "For whom are the new standard?"
I like the idea to get a standard but isn't that a little bit late for a major change like that?!

As i said before i'am only a user (most of the time!) but if there will be a faster and better and safer way to do thinks on my 3DS's i would like to test it and if i dont like it change it back!
And at the moment i dont see a way back for me

I like the way Dev's are talking behind walls trough all this and try to make a decision ........ but ALL they do is FREE and the decisions they make have a MAJOR impact to all of us useres. Also i dont think that ALL Dev's are working in that direction if the decision leads to a new standard maybe we will have to deal with a more complex structure as now!

ALL of the above are a personal meaning but i think some of it could get a warm place in the Dev talking behind the walls

 

[Tjessx]

sdmc:/
[INDENT]3DS/
[INDENT]bin/
boot/
etc/
log/[/INDENT][/INDENT]

I think it is a good idea to set some standards over more then just the app location, such as the etc and log folder, However
I think we should oversimplify the names, this will be confusing for A LOT of people, and we may think that it is straight forward, and you'll just see what's in there and people know, but people are real idiots on this kind of thing.

Imagine all the spam threads this will bring up on this forum

Maybe rename it like this:

sdmc:/
   3ds/
      apps/
      arm9/
      cfw/
      files/
      log/

EDIT:
When releasing your homebrew it might be a good idea to keep the same homebrew structure in a zip/rar when using files, when you're not using files it would be best to just release the 3dsx/cia.

an example of a rar of a 3dsx with files:

sdmc:/
   apps/
      applicationname/
         applicationname.3dsx
      files/
         applicationname/
            settings.txt

This way 3dsx download applications could go so much further.

--------------------- MERGED ---------------------------

I agree 100%. If they won't switch to the new standard (whatever it may be) that's their loss. Let their code be RE'd and fixed up for all I care.

The point is that we're going to break backwards compatibility here, inevitably. Users need to prepare for that.

if we keep the 3ds folder, and put an apps folder in there, it will be backwards compatible

 

[Shadowhand]

*snip*

sdmc:/
   3ds/
      apps/
      arm9/
      cfw/
      files/
      log/

This is dumb, because there's literally no need for cfw/ or arm9/ or files/ or log/, all you need is /3ds/, and then each folder being a single folder for one application within the system be it 3dsx or not.

sdmc:/
   apps/
      applicationname/
         applicationname.3dsx
      files/
         applicationname/
            settings.txt

And this is dumb because you're fragmenting things further.

Not to mention, my idea for a unified folder for homebrew is not just for .3dsx, in fact, it's mostly for the FILES of homebrew.

 

[Wolfvak]

So after some discussion on the discord channel of 3DS Hacking, a few of us came up with a format and want to know what you guys would think of it. I understand that /Homebrew/ is great and all, but the main issue with it is that while it is easy to identify, there's no guarantee the Wii U or Wii scenes will pick up on this, and only fair to assume they will not for now until they've shown interest in a possible merge. We came up with the following, based on the Linux file system:

sdmc:/
    3DS/
      bin/
      boot/
      etc/
      log/

Now here's the explanation: /bin/ is for homebrew binaries which are just going to be a 3dsx file alongside their smdh meta. It'd be simplified if we have those who use this homebrew format embed the smdh to the 3dsx since that can be done now. Furthermore, /boot/ is for arm9-based stuff. luma/payloads/ could be in there for Luma's executable boot payload files. The config would be placed inside of /etc/ under the folder labeled /luma/config.txt as it plainly is etc and would not fit in any other folder. Homebrews that have external files such as JKSM could plop output in there under /etc/JKSM/ or applications that rely on external data like Love Potion would place the game files inside of /etc/{appname}/{files}. Finally, /log/ is where any 3dsx or cia application logs would be placed. Luma3DS could dump its register error information in a format close to Luma_2-7-16_01:27.log.

If anyone needs more examples I will gladly provide them. Yes, this does not fix the minor issue that some use the same SD card, but it would clean up the mess they have from the scene.

UNIX, is that you?

 

[Tjessx]

sdmc:/
   3ds/
      apps/
      arm9/
      cfw/
      files/
      log/

This is dumb, because there's literally no need for cfw/ or arm9/ or files/ or log/, all you need is /3ds/, and then each folder being a single folder for one application within the system be it 3dsx or not.

sdmc:/
   apps/
      applicationname/
         applicationname.3dsx
      files/
         applicationname/
            settings.txt

And this is dumb because you're fragmenting things further.

Not to mention, my idea for a unified folder for homebrew is not just for .3dsx, in fact, it's mostly for the FILES of homebrew.

Let's say you've got 50 homebrew applications, 30 Cia applications, you've got 3 CFW on your SD card and you are using arm9.
If you put that in a single folder, you have to manually search for a specific folder you're busy pretty long.
1 folder for all is dumb.

 

[chaoskagami]

Let's say you've got 50 homebrew applications, 30 Cia applications, you've got 3 CFW on your SD card and you are using arm9.
If you put that in a single folder, you have to manually search for a specific folder you're busy pretty long.
1 folder for all is dumb.

Tell me what the rational difference is between CFW and ARM9 applications. Dare you.

 

[Shadowhand]

Let's say you've got 50 homebrew applications, 30 Cia applications, you've got 3 CFW on your SD card and you are using arm9.
If you put that in a single folder, you have to manually search for a specific folder you're busy pretty long.
1 folder for all is dumb.

It will not be one folder for all.
The current /3ds/ folder is literally only used for .3dsx format homebrew. By HomebrewLoader. If you move that folder to /homebrew/3ds/hbloader (which will have HANS and what not in it), it'll be used by the Homebrew Loader.
I also would like to explain that all CFWs are also homebrew apps that save files to the root of SD, and we don't need a folder to put arm9 files because the lovely bootmanagers we have give us config files to point to any folder. I use /homebrew/3ds/_boot/ for my a9lh payloads for example, but that doesn't have to be a standard.

 

[chaoskagami]

It will not be one folder for all.
The current /3ds/ folder is literally only used for .3dsx format homebrew. By HomebrewLoader. If you move that folder to /homebrew/3ds/hbloader (which will have HANS and what not in it), it'll be used by the Homebrew Loader.
I also would like to explain that all CFWs are also homebrew apps that save files to the root of SD, and we don't need a folder to put arm9 files because the lovely bootmanagers we have give us config files to point to any folder. I use /homebrew/3ds/_boot/ for my a9lh payloads for example, but that doesn't have to be a standard.

I think what we're getting at here is the following perhaps: Do we do application folders (like OSXs .app and .bundles), or do we split up different types of data to clarify their purpose (unix-style?)

On one front - application folders are self contained. On the other, it's very hard to figure out what that application provides without unix-style organization, if someone were to code something like JKSV for homebrew.

Users want the former, but it's almost always a pain for developers. It's also why we're in this mess in the first place.

 

[Shadowhand]

we do application folders (like OSXs .app and .bundles),

This is what I'm envisioning. What I propose is we literally use /homebrew/3ds/ like we use SD root. That way only very little will have to be changed on both developer and user sides.

 

[Tjessx]

It will not be one folder for all.
The current /3ds/ folder is literally only used for .3dsx format homebrew. By HomebrewLoader. If you move that folder to /homebrew/3ds/hbloader (which will have HANS and what not in it), it'll be used by the Homebrew Loader.
I also would like to explain that all CFWs are also homebrew apps that save files to the root of SD, and we don't need a folder to put arm9 files because the lovely bootmanagers we have give us config files to point to any folder. I use /homebrew/3ds/_boot/ for my a9lh payloads for example, but that doesn't have to be a standard.

if we don't move the 3ds folder, which would be silly, then it will be backwards compatible with older versions of the homebrew launcher, and the newer versions of the homebrew launcher (or a forked one) could just point to the correct folder (if it exists, else just 3ds)

 

[Shadowhand]

if we don't move the 3ds folder, which would be silly, then it will be backwards compatible with older versions of the homebrew launcher, and the newer versions of the homebrew launcher (or a forked one) could just point to the correct folder (if it exists, else just 3ds)

The current HBL is a little wonky in its way to figure out what is an app, and what is not, and it's just a whole bunch of clusterfuck. Gridlauncher tried bringing some sort of standard to this behaviour, but it ended up fucking up some apps that come default (sploit installers comes to mind). Even if we use /3ds/, we still need a newer version of HBL that deals with it, so it won't be backwards compatible. I think this is one of the rare instances where backwards compatibility should be sacrificed for the betterment of the entire scene.