General Save directory?

[Wally]

Folks I had a thought last night regarding save data and was thinking what if we had a "SaveData" directory standard where any save data from emulators go.

I can only think of benefits as it'll be much easier to backup that folder than have to look through a mess of AppData, copying individual save files from each set folder. Some games / emulators require additional data in the AppData Folder so it'd be nice to be able to avoid having to copy that across

Thoughts?

 

[levi]

What's wrong with Eki's BGS?

 

[Tenka]

This'd only make it easier on BGS, with a standard location the world won't end when BGS does.  Yep I'd like this too.

 

[Wally]

What's wrong with Eki's BGS?

Nothing. I just think we need a more concrete solution as BGS doesn't cover everything.

 

[_wb_]

Are you reinventing the user home directory here?

The point of PNDs and appdata was exactly that the settings and savefiles associated with a PND would end up being stored on the same SD card as the PND itself, as opposed to the NAND (or a potentially different SD card if your home dir is on an SD card), which would be the default behavior since most *nix programs write to ~ by default.

If you want to backup everything, just copy the entire appdata directory.

The only problem is that some emulators and other programs use appdata for other things than user settings and saves. E.g. data files like ROMs. One potential solution is to put the data in some other directory and make symlinks to it from appdata. Then when you make a backup you just have to make sure that you make a copy that does not dereference the symlinks.

Perhaps if we're going to revise the PND system, we could make a more fine grained distinction between things. E.g. instead of putting everything in appdata, we could have three folders: app_settings, app_saved_data, and app_data. The idea would then be that app_settings contains only small config files etc, app_saved_data can contain bigger files like save states, and app_data contains the non-user-created data like game assets and ROMs. That way it's easy to make a backup of only the things you care about. Also you can easily do a "factory reset" by removing app_settings, without losing your saved games, or remove save states without losing your settings.

Another option would be to just save all user settings and data in ~, since there is no reason anymore to assume that there is not enough space there, and use appdata only for non-user-created data. That way doing a backup is just making a copy of /home.

 

[slaeshjag]

Just letting everything dump their settings in ~ can be annoying if you for some reason want to move your programs/games between pandoras, since you then have to copy the conf back and forth between them.

A practical problem of splitting up the appdata into different directories would be that pretty much all programs/games that save more than just config, needs to be modified to use the different directories. Will that actually happen? If not, you'll have an even greater mess of potential locations for your savegames to be in.

 

[Wally]

The way I see it.. 

Appdata is for settings / config

Savedata could be for save data or documents.


So games like Duke 3D Would use AppData for the GRP file and any necessary files to run where as Savedata could be used to store the save files / screenshots.

Kinda reinventing the wheel but it makes a lot more sense than having to backup one entire directory.

 

[klapse]

I think my vote would be to keep things in the PND. Alternatively do it the good old linux way and put it in home.

 

[FIQ]

If we are going to change stuff, I suggest you could simulate a portable home directory (<sdcard>/home) and store things there following the xdg directory standard.

However, I don't exactly see the issue here beyond flaws resulting by the PND system itself.

 

[bzar]

I'd rather see a better way of managing additional game data, such as game asset files and ROMs. Toss those out of appdata and it will mostly contain settings and saves, eg. the stuff you actually want to back up. I suggest directories appdata and userdata, with unionfs mount order PND (ro), appdata (ro) and userdata (rw). Put commercial game data files and other non-changing stuff into appdata, backup userdata.

EDIT: The issue I see with Wally's savedata suggestion is that it requires applications to support it explicitly, since it specifies a second directory that can be saved into.

EDIT2: My suggestion is also fully mostly backwards compatible

 

[thatgui]

Don't see the need for a redesign, just a way to "enforce" the basic principle that is already there. I already made several approaches in the past to convince people that its a good thing to keep game and user data seperated, but people (pnd maintainers and users alike) just want to throw everything together (at least it looks like that to me)

 

[_wb_]

I'd rather see a better way of managing additional game data, such as game asset files and ROMs. Toss those out of appdata and it will mostly contain settings and saves, eg. the stuff you actually want to back up. I suggest directories appdata and userdata, with unionfs mount order PND (ro), appdata (ro) and userdata (rw). Put commercial game data files and other non-changing stuff into appdata, backup userdata.

EDIT: The issue I see with Wally's savedata suggestion is that it requires applications to support it explicitly, since it specifies a second directory that can be saved into.

EDIT2: My suggestion is also fully mostly backwards compatible

Or without changing anything, we could just ask PND maintainers to not put read-only game data that is not in the PND in appdata, but instead to ask the user where they want to put it. E.g. most emulators already do that -- they don't assume a fixed path somewhere in appdata for the ROMs, but they let the user pick a ROM folder and remember the last visited folder.

The same could be done for e.g. open sourced game engines that need proprietary game data. As a default directory for such things, we could call it "appdata_readonly" and provide the PND scripts with some easy way to find their folder (e.g. $APPDATA_READONLY or something).

 

[slaeshjag]

Hypothetically, if I were to implement it in my dbp-system, and lets assume it or simlar system with that feature made it onto the pyra. Do you think anyone would use it? Would enough packages use it for it to be less confusing than the current situation?

 

[bzar]

I'd rather see a better way of managing additional game data, such as game asset files and ROMs. Toss those out of appdata and it will mostly contain settings and saves, eg. the stuff you actually want to back up. I suggest directories appdata and userdata, with unionfs mount order PND (ro), appdata (ro) and userdata (rw). Put commercial game data files and other non-changing stuff into appdata, backup userdata.

EDIT: The issue I see with Wally's savedata suggestion is that it requires applications to support it explicitly, since it specifies a second directory that can be saved into.

EDIT2: My suggestion is also fully mostly backwards compatible

Or without changing anything, we could just ask PND maintainers to not put read-only game data that is not in the PND in appdata, but instead to ask the user where they want to put it. E.g. most emulators already do that -- they don't assume a fixed path somewhere in appdata for the ROMs, but they let the user pick a ROM folder and remember the last visited folder.

The same could be done for e.g. open sourced game engines that need proprietary game data. As a default directory for such things, we could call it "appdata_readonly" and provide the PND scripts with some easy way to find their folder (e.g. $APPDATA_READONLY or something).

Well, it has the downside of requiring a coordinated effort by multiple people, which lowers the chances of it seeing a widespread adoption at this point.

I'd actually modify my suggestion to have appdata and appdata-ro. appdata-ro is mounted only if it exists. This way all existing configurations work by default and people can just pop stuff into the readonly tree as they please. Now it's fully backwards compatible

 

[_wb_]

I'd rather see a better way of managing additional game data, such as game asset files and ROMs. Toss those out of appdata and it will mostly contain settings and saves, eg. the stuff you actually want to back up. I suggest directories appdata and userdata, with unionfs mount order PND (ro), appdata (ro) and userdata (rw). Put commercial game data files and other non-changing stuff into appdata, backup userdata.

EDIT: The issue I see with Wally's savedata suggestion is that it requires applications to support it explicitly, since it specifies a second directory that can be saved into.

EDIT2: My suggestion is also fully mostly backwards compatible

Or without changing anything, we could just ask PND maintainers to not put read-only game data that is not in the PND in appdata, but instead to ask the user where they want to put it. E.g. most emulators already do that -- they don't assume a fixed path somewhere in appdata for the ROMs, but they let the user pick a ROM folder and remember the last visited folder.

The same could be done for e.g. open sourced game engines that need proprietary game data. As a default directory for such things, we could call it "appdata_readonly" and provide the PND scripts with some easy way to find their folder (e.g. $APPDATA_READONLY or something).

Well, it has the downside of requiring a coordinated effort by multiple people, which lowers the chances of it seeing a widespread adoption at this point.

I'd actually modify my suggestion to have appdata and appdata-ro. appdata-ro is mounted only if it exists. This way all existing configurations work by default and people can just pop stuff into the readonly tree as they please. Now it's fully backwards compatible

Yes, that's the way to do it. It solves the problem and does not require anyone to do anything (only the PND mount script needs a tweak). It's a flexible solution: as a user you can decide what to put where and what you want to backup. Just put your roms and game data in the appdata-ro, and it will magically work without having to change any existing PND. I like it.

 

[bzar]

I do think "appdata-ro" is a clunky name. Any ideas for a better one?

 

[FIQ]

assets?

 

[_wb_]

I do think "appdata-ro" is a clunky name. Any ideas for a better one?

appreadonly

ro-data

readonly

romdata

approms

data

Maybe we could change the entire naming system, with the old names still supported but the new names also available and encouraged.

Instead of

/pandora/menu

/pandora/apps

/pandora/desktop

/pandora/appdata

/pandora/appdata_ro

we could use these names:

/dragonbox/applications/

/dragonbox/applications/desktop

/dragonbox/applications/desktop_only  (probably not a very necessary thing to have, why would you put it on the desktop but not in the menu?)

/dragonbox/settings

/dragonbox/data

Of course for backwards compatibility, the old names could still be used. But e.g. tools like PNDManager could use the new names, and users who want to use the new  names (if they think they make more sense / look nicer) can do so if they want to.

 

[notaz]

Has anyone checked if such triple union mounting actually works with aufs?

We could already implement it on pandora and get it tested.

 

[bzar]

I was under the impression it would, at least. Docker utilizes AUFS and layers multiple FS images on top of each other to create runnable containers. AUFS project description's first sentence is "Advanced multi layered unification filesystem.". Not that it could not be unable to perform such a task, but if I'm wrong at least I have a good defense for myself ready h34r: