Atmosphere: Multiple "contents" folders: one for system titles, one for user-provided titles

[natinusala]

What would you think about having two contents folders:

• one containing the "system" titles currently bundled in the releases
• another containing the user-provided titles only (would be empty or left out in release archives)

That would:

• allow knowing which titles are user installed versus which are Atmos reimplementations
• prevent accidental deletion of "system" titles
• make it easy to reset the Atmos install (just empty out the user provided titles folder)

The use case here is someone installed too many sysmodules (preventing the console from booting) and wanted to remove all of them. In the end they had to remove the contents folder and put back the files from the Atmos release.

[Clydefrosch22]

i suggested something similar a while ago, but with subfolders inside contents here https://github.com/Atmosphere-NX/Atmosphere/issues/870
Definitely support anything that helps manage that folder.

[UnderRev0lved]

That's what I exactly thought.
That would be a welcome improvement

[misson20000]

Reminds me of how systemd has separate directories for package-provided unit files and hand-written unit files. On that note though, dealing with multiple software distributions that all place files in a common directory tree smells a lot like a general package management problem.

Separating AMS content from user content is a very good start, but I would love to see package management be like what we've done for exefs_patches, where they are grouped by patchset: a packages/ directory where each directory represents a different software distribution and has its own contents/, exefs_patches/, etc. directories. Perhaps even specify a manifest with information like human-readable package name, author, release date, homepage, license, supported AMS versions, supported HOS versions, etc., not so much for AMS to use as to create a standard for homebrew package managers to use.

• atmosphere/
  
  
  
  • contents/
  
  
  • (AMS distribution contents)
  
  
  • kip_patches/
  
  
  • (AMS distribution kip patches)
  
  
• packages/
  
  
  
  • my_epic_botw_mod/
  
  
  • (AMS directory tree format replicated here)
  
  
  • contents/
    
    
    
    
    
    • 01007EF00011E000/
    
    
    
    • (...)
    
    
    
  
  
  • exefs_patches/
    
    
    
    
    
    • (patchset name optional here, since it's kinda redundant with this format)
    
    
    
    • 2094F152836683A3632C6153FD84AB80.ips
    
    
    
  
  
  • manifest.ini
  
  
  • some_sysmodule
  
  
  • flags/
    
    
    
    
    
    • disable.flag
    
    
    
  
  
  • contents/
    
    
    
    
    
    • 0100000aabb00001/
    
    
    
    • exefs.nsp
    
    
    
    • flags/
      
      
      
      
      
      
      
      • boot2.flag
      
      
      
      
    
    
    
  
  
  • manifest.ini
  
  
  • sysmodule_with_multiple_titles_like_twili
  
  
  • contents/
    
    
    
    
    
    • 0100000000006480/
    
    
    
    • 0100000000006482/
    
    
    
  
  
  • manifest.ini
  
  

[HookedBehemoth]

supported AMS versions, supported HOS versions

I'd love to have this feature.

The manifest could also be expanded to e.g. emuMMC on/off, Calcio/Hoag/...

[SciresM]

I am mostly okay with this conceptually.

[cheesycod]

I like the idea, however this could be more confusing to the users. Also, we can't easily migrate existing installs to this

[natinusala]

We don't need to migrate anything since the current folder will still work, we'll just need to encourage users to move their stuff to the new folder

[fennectech]

That will be the first thing I do if/when this gets implemented Not having to pick through the contents folder to delete sysmodules without deleting mods would be a godsend. As for migration, We could move any directory corresponding to a published Nintendo game. While it's not perfect it would get the vast majority of titles.

[ELY3M]

I agree with this idea.

[fennectech]

The ability to add names after the folder title IDs would also be incredibly nice

[SciresM]

No matter what solution we take regarding multi-contents-folder support, atmosphere is never going to allow non-program id folder names (or text after the program id). The complexity overhead is flat out not worth it, it introduces entirely new classes of error case bullshit (like two or more folders with the same program id).

It turns a simple one way mapping via string format into an ambiguous operation that requires a full directory scan.

Not happening.

[fennectech]

Makes alot of sense. Ill jsut have to stick to my text file index solution