Atmosphere: Feature: Per-user LayeredFS

[AnalogMan151]

Since the Switch is much more family oriented than individual oriented like the 3DS was, having mods be loaded based on profile played would be an appreciated feature. Something as simple as adding a username to the end of a title folder like so:

├── 01007ef00011e000_User01
│   └── romfs
└── 01007ef00011e000_User02
    └── romfs

If a folder has no user name after it then the mod is loaded for all user accounts. This would allow one to add mods only for their own profile or add different mods based on who loads the title.

[Luro02]

this would cause problems, if someone has their name in for example kanji....so using (alternatively) the account ID should be an option too ?!

[griest024]

This would certainly be helpful but it wouldn't have to be implemented in CFW. You could accomplish essentially the same behavior with a good mod manager homebrew.

[CobaltTiger]

As I recall, there was a homebrew app on the 3DS that did exactly that, minus the multi-user thing. Conceptually, it's really similar, so I wonder if it couldn't just be ported?

[griest024]

That does sound familiar. However it might be more complicated than that. In order to figure out which user is playing the game, you would have to have access to some hook that gets called after user selection but before the title is loaded (that is assuming that layeredfs files can't change after the title is loaded, which I imagine is the case).

What's far simpler is to just have manual switching rather than user based. And in that case, it makes sense to have a standalone mod manager.

[misson20000]

See acc:u1#GetLastOpenedUser

[fennectech]

I beleve layeredfs content can change. Ive re uploaded content while the game is running and it resulted in a crash. So changing the files on the disk does have some effect on layerFS

[griest024]

It might work out fine for some minor content but for LFS files that change major things (i.e. the executable), I can't see how that could be dynamically injected and actually work as intended.

[AnalogMan151]

While a homebrew can certainly do this, it's outside the scope of this request. This is for benefitting the end users, especially those who are not familiar with homebrew. With the Switch being a household unit, there will be instances were the people playing it are not the person who hacked it and thus will not know to to first open a homebrew and adjust the installed mods. Having it built right into the CFW would be ideal for a non-technical person's standpoint.

Plus, if this is implemented it would make creating a homebrew to manage per-user mods much easier.

[ThatNerdyPikachu]

I'll implement this, look out for a PR soon...

[ThatNerdyPikachu]

(only thing i may not be able to do is the part where one folder gets loaded always..)

[AnalogMan151]

For clarification, I didn't mean both a universal folder and also a user folder getting loaded, I mean, check to see if a user specific folder exists and load the romFS from that, if it doesn't, then check to see if a non-user specific folder exists, then load that. Kind of like a fall back.

[ThatNerdyPikachu]

@AnalogMan151 Oh, that's what I thought you meant initially. Thanks for the clarification!

I'll PR later today.

[Selver-gba]

Hmmm.... If this is limited to when the file system loads, it might work. However, I wonder if this would fail badly for any module that's already loaded. (cached data, callbacks expecting different data, timers set with user A logged in, firing with user B logged in, etc.)

But just limited to items not loaded yet, and which are guaranteed to unload when the user switches? Yes, that's interesting.

[SciresM]

This turns out to be basically not feasible due to a lack of good way to represent users inside filepaths (user names not unique, user ids inconvenient and unintuitive, special characters are a problem, etc)

[AnalogMan151]

This is a sad day.

[WerWolv]

Aren't users stored in a list that is always in the same order? How about using "indexes" into that list then as folder name?
Even if you add a new user it should just get added to the back of that list so it wouldn't interfere with it and it would be much more intuitive that userIDs and still unique for that console.
Deleting users would change the list but tbh that's something that doesn't happen very often.

[bakugo]

user ids inconvenient and unintuitive

How are user ids more inconvenient or unintuitive than title ids?

[shchmue]

user ids inconvenient and unintuitive

How are user ids more inconvenient or unintuitive than title ids?

title IDs you can look up online; they can be put in the instructions for the mod or other title replacement, user IDs you'd have to dump with homebrew or LibHac. and they'd be 32 characters long afaik, oof

[SciresM]

@shchmue user IDs are actually 128 bits.

[AnalogMan151]

And IPS patches are 256bit, so I don’t think character length is a consideration.

[SciresM]

@AnalogMan151 user IDs are console-specific, and cannot be looked up on the internet -- and IPS patches can be named by devs for users who do not know how to use SHA256.

[shchmue]

@shchmue user IDs are actually 128 bits.

yeah that's 32 hex characters right

And IPS patches are 256bit, so I don’t think character length is a consideration.

those live in their own files, this would be part of the file path

[AnalogMan151]

Right, IPS patch names are the SHA256 of the kip they alter so it’s part of the file path too.

[roblabla]

how about transliterating the user's name to ASCII, similar to https://github.com/dzcpy/transliteration ? IIRC libicu (we have libicu in homebrew, right?) supports it, you can find an example here. It's not the greatest, but it'd be a good middleground, and a homebrew could provide the username with its transliterated name.

[shchmue]

Right, IPS patch names are the SHA256 of the kip they alter so it’s part of the file path too.

there's nothing 'past' them though, this puts a potentially deep folder tree beyond a long foldername

[AnalogMan151]

True. Unless we did something that like matching only the first 32 or 64 bits. It’s unlikely two accounts on one Switch would have similar enough IDs to have multiple matches.

[SciresM]

We're not using user-ids.

[SciresM]

@roblabla as mentioned, usernames are not unique

[roblabla]

Is that really a problem though? Transliterated names are not unique either. Worse-case scenarios, two users will share the same mod path. It won't cause crashes, but it might cause confusion.

[SciresM]

Yes, I don't intend to accept a feature that doesn't uniquely identify users.

[SciresM]

In addition, this creates a huge amount of cruft throughout codebase -- suddenly all of loader needs to run twice, checking both exefs and exefs_<identifier>, and code needs to be written to only run a second path after account has been initialized and can be connected to. It sounds super, super gross from a code maintenance perspective.

[AnalogMan151]

I understand. I only suggested it because the current approach is carried over from the 3DS which was a single user system and isn’t quite suited for the multi-user system of the Switch. It just feels odd to have a single-user solution on a multi-user platform. I’m sure it would have been more useful to have approached this from the beginning rather than adapting the current system.

[SciresM]

I mean I think fundamentally user-profile stuff is just extremely weird to integrate into loader/FS -- it requires talking to account, which is launched fairly late and itself heavily dependent on loader/FS...and the only way the active user gets set is when the profile selector runs, and the whole thing just gets messy.