General Save directory?

[slaeshjag]

My impression of it is that you can have more than two unified folders, but that should be easy enough to test for anyone that cares enough about this feature

 

[bzar]

Well, at least the mount command goes through and it's readable. Wasn't able to write to it but that must've been just some missing options and stuff . The command I tried was really bare bones.

 

[thatgui]

Would it be possible to extend this so the "appromwhateverdata" folder could just be the users home dir - preferably per user choice, or even application or storage (where the pnd/pndsuccessor resides on) based.

simple proposal: appdate gets renamed to "userdata" and contains config/saves/etc. , datafiles/roms/etc. go into "bindata".

 

[bzar]

Would it be possible to extend this so the "appromwhateverdata" folder could just be the users home dir - preferably per user choice, or even application or storage (where the pnd/pndsuccessor resides on) based.

Does symlinking the appdata directory to your home directory work?

 

[thatgui]

Would it be possible to extend this so the "appromwhateverdata" folder could just be the users home dir - preferably per user choice, or even application or storage (where the pnd/pndsuccessor resides on) based.

Does symlinking the appdata directory to your home directory work?

Guess so, never tried though, always worried to fill up the NAND. Also noticed a mistake in my request, I intended to ask for the "userdata" part not the app/romdata directory

 

[bzar]

Would it be possible to extend this so the "appromwhateverdata" folder could just be the users home dir - preferably per user choice, or even application or storage (where the pnd/pndsuccessor resides on) based.

Does symlinking the appdata directory to your home directory work?

Guess so, never tried though, always worried to fill up the NAND. Also noticed a mistake in my request, I intended to ask for the "userdata" part not the app/romdata directory

In the proposed model, you could do exactly that

 

[WizardStan]

Would it be possible to extend this so the "appromwhateverdata" folder could just be the users home dir

For what purpose?The PND system already "tricks" applications into thinking home is the appdata directory, it could arbitrarily be changed to a single directory on the SD card instead of individual per-PND directories.

All these PNDs are already self contained, remove the card and it doesn't matter if the "home" directory disappears because the app is gone too. You put actual home on an SD card and you're asking for trouble. What happens when the system writes a config file to your home and then you swap the card?

Given the size of the internal storage, I would almost argue the opposite: there's no longer any need for PNDs to redirect home to the SD card, we can just keep it on the internal flash. Almost, I say: having the appdata directory still makes it easier to delete something when you're done with it, no need to go wading through a centralized home directory looking for old files that are no longer needed.

 

[thatgui]

Would it be possible to extend this so the "appromwhateverdata" folder could just be the users home dir

For what purpose?
The PND system already "tricks" applications into thinking home is the appdata directory, it could arbitrarily be changed to a single directory on the SD card instead of individual per-PND directories.


All these PNDs are already self contained, remove the card and it doesn't matter if the "home" directory disappears because the app is gone too. You put actual home on an SD card and you're asking for trouble. What happens when the system writes a config file to your home and then you swap the card?


Given the size of the internal storage, I would almost argue the opposite: there's no longer any need for PNDs to redirect home to the SD card, we can just keep it on the internal flash. Almost, I say: having the appdata directory still makes it easier to delete something when you're done with it, no need to go wading through a centralized home directory looking for old files that are no longer needed.

Hmm, maybe I did not express my idea right in that case (or practically any case today): The idea was that the user could choose were he/she/it wants the user data to be stored: either on the same or another storage device in an application specific folder (as it is currently implemented), or in the users home directory on the internal storage.

Personally I would like to have the specific pnd on the internal memory, user data in my home dir on the internal  memory too, while the memory intensive stuff (roms, datafiles, ect) would reside on the SD card.

 

[WizardStan]

or in the users home directory on the internal storage

Oh, I see. Sorry, I interpreted that opposite to what you meant. My mistake. Yes, that's reasonable.

 

[double7]

 

[bzar]

double7: How do you feel about my suggestion? No dev support required, no per-app-configured-exclude required, user created content in a single directory tree, optional and flexible to use.

(to refresh your memory: add another appdata directory for readonly stuff alongside the writable one and use it as a second readonly layer mounted with the PND and appdata if it exists)

 

[double7]

add another appdata directory for readonly stuff alongside the writable one and use it as a second readonly layer mounted with the PND and appdata if it exists)

I think i missunderstood your mounting description at first. Your idea is like mine, except you are on pandora/appdata root directoy level and i'm on appdata/app dir level.


Hmm, i think it depends. How many apps are really affected to Wallys backup problem?


If you don't want dev support, how do you move the RO files to your appdata_RO dir? It means manual action or per-app-configuration-moves, just like per-app-configured-excludes.


Per-app-configured excludes don't need to be per-app, a *.rom, *.wad may fit many apps.


That is valid for your idea too, reflecting the mask, an automatic movement script based on the same in/excludes configuration actions is possible. I think the complexity is even there.


Again, how many apps are affected?


Not many? - Are we really want to implement that feature for all other apps?


Many? - How will the restore of that backup will be then? If your SD becomes inaccessable you get your empty new one, restore your appdata backup without the big *.rom and *.wad files - and install many *.wad to correct locations by hand again? I'm sorry, i do backups because i don't want to do all those installation and configuration actions again!


But i'm like Wally too, i do like to avoid big RO files being copied during backups again and again. I want to reduce backup time and storage wear. And i want an instant working restore.

Thats why i prefer the solution on the side of the backup process.

But i didn't walk in Wallys moccassins, maybe his dual 256GB SD cards and his 1TB USB3-stick may require too much space for a full backup.   Well, then the --exclude function of rsync would help.

As i see now, grsync needs the --exclude options manually entered in text form on the advanced options box. A file browser would be more user comfortable, but if you really want exclusion you cloud get it.

 

[bzar]

add another appdata directory for readonly stuff alongside the writable one and use it as a second readonly layer mounted with the PND and appdata if it exists)

I think i missunderstood your mounting description at first. Your idea is like mine, except you are on pandora/appdata root directoy level and i'm on appdata/app dir level.

Yes, as a working name I call them appdata (read-write) and appdata-ro (read-only). These exist inside the pandora directory side by side. All three (PND squashfs, appdata-ro and appdata) will be aufs-mounted on top of each other on PND mount. Except for the cases where appdata-ro for the application does not exist. Then the mounting will proceed as it does now.

Hmm, i think it depends. How many apps are really affected to Wallys backup problem?

It's not only for the backups either. Consider it a custom base state for the PND. For a quick example, use an application that has plugins and saved state? Put your plugins to the readonly appdata and you can restore the application to with-plugins zero state by deleting its writable appdata.

If you don't want dev support, how do you move the RO files to your appdata_RO dir? It means manual action or per-app-configuration-moves, just like per-app-configured-excludes.

For new PNDs you may, if you want, put the RO files there in the first place. For existing applications sure, you need to move the files, but it's still less work than coming up with exclude rules and updating scripts. Some people have a LOT of PNDs. You expect them to manually maintain a list of exclude rules?

Per-app-configured excludes don't need to be per-app, a *.rom, *.wad may fit many apps.


That is valid for your idea too, reflecting the mask, an automatic movement script based on the same in/excludes configuration actions is possible. I think the complexity is even there.

There does not need to be any automatic moving. It's a one-time deal of just putting the RO data to the right place. You'd probably do it by hand in less than five minutes. No need for any scripts to do this. For backupping with excludes you do need scripts since you do it multiple times. In addition you introduce a failing point in your backup system, namely bad exclude rules. One of those might stop important files from being copied. Sure it's easy when you consider a few PNDs, but does the solution scale?

Again, how many apps are affected?


Not many? - Are we really want to implement that feature for all other apps?


Many? - How will the restore of that backup will be then? If your SD becomes inaccessable you get your empty new one, restore your appdata backup without the big *.rom and *.wad files - and install many *.wad to correct locations by hand again? I'm sorry, i do backups because i don't want to do all those installation and configuration actions again!


But i'm like Wally too, i do like to avoid big RO files being copied during backups again and again. I want to reduce backup time and storage wear. And i want an instant working restore.


Thats why i prefer the solution on the side of the backup process.


But i didn't walk in Wallys moccassins, maybe his dual 256GB SD cards and his 1TB USB3-stick may require too much space for a full backup.   Well, then the --exclude function of rsync would help.


As i see now, grsync needs the --exclude options manually entered in text form on the advanced options box. A file browser would be more user comfortable, but if you really want exclusion you cloud get it.

The feature won't affect any apps that the user doesn't make it affect. It's probably 2-3 lines more in the PND mount script and only does anything if the appdata-ro directory exists for the executed PND. If you don't have an appdata-ro directory, you won't even see anything being different.


For restoring RO data: If you want to back up everything, you should back up the entire pandora directory to get the PNDs as well or even the entire SD card. In that case appdata-ro will be included just as nicely if you've chosen to use it for the other benefits.


That's not how at least I do backups, however. I want to only backup stuff I can't get elsewhere, eg. stuff I've created (using the word in a broad sense here: I'm counting game saves and highscore files and documents alike as stuff I've created using an application). All the other data is available elsewhere. Restoring a backup should be a very rare occasion. For example, I just checked my home directory size on this computer, and it stands at 187 GiB. There's not much point backing all that up since I can restore around half of it from Steam (though I wouldn't since I've finished many of the games occupying that space). If you can get all your data back somehow, you're in the clear no matter if it takes a while. In a normal case, you just about never need to do it.


Anyway, it's all moot. This system is an optional one. Feel free to not use it and continue putting everything in one place and writing exclude rules as you will . It will not harm you in any way whatsoever if this system exists. No one is forced to use it and nothing can depend on it being used. It's one more way of managing your data and fixes some issues for some people without making life any harder for the rest.


In short:


Back up everything? Rsync the pandora directory.


Back up user created files? Rsync pandora/appdata.


Customize a PND with a readonly layer? Put it in appdata-ro.

EDIT: Sorry for the tone, I was tired

 

[slaeshjag]

I have now implemented B-ZaR's suggestion in dbp, with an optional flag in config-file to automatically create the rodata directory for packages.

 

[double7]

Sorry for delayed answer, i wrote yesterday but failed to post 'caus i had to go to work.

For a quick example, use an application that has plugins and saved state? Put your plugins to the readonly appdata and you can restore the application to with-plugins zero state by deleting its writable appdata.

How can i do that restore if my plugins are in the appdata-ro which is not backed up? If any kind of easy reset functionality is required it should be the task of the app developer to provide savestate or config directories.

how do you move the RO files to your appdata_RO dir? It means manual action

For new PNDs you may, if you want, put the RO files there in the first place. For existing applications sure, you need to move the files, but it's still less work than coming up with exclude rules and updating scripts. Some people have a LOT of PNDs. You expect them to manually maintain a list of exclude rules?

Yes, i do. I do as you, expect them to take manually actions to achieve their requirements.
And i can't see your difference in first installation or later movement of files. Both are "from source to destination" actions, no matter if you use a gui or cli. The difference is holding another key while mouse movement or typing "mv" instead of "cp".

Additionally we forgot something, i think. You have appdata and appdata-ro, but what about the app dir itself? Your real appdata is in appdata/appname, you have appdata-ro and then? How is appdata-ro/appname created?

Do you want to throw all appdata-ro files of all apps into one single appdata-ro dir?

Do you want to manually create appdata-ro/appname for "a lot" of apps?

Do you want auto creation of all appdata/appnames into appdata-ro/appnames?

Do you really think finding the folders via the gui in dozens of empty dirs is less work?

I think the complexity is even there.

There does not need to be any automatic moving. It's a one-time deal of just putting the RO data to the right place. You'd probably do it by hand in less than five minutes. No need for any scripts to do this. For backupping with excludes you do need scripts since you do it multiple times. In addition you introduce a failing point in your backup system, namely bad exclude rules. One of those might stop important files from being copied. Sure it's easy when you consider a few PNDs, but does the solution scale?

Yes, because it doesn't need scripts as you said. It is one script only and you never touch the script again after it's ready. You would have one exclude file list, which could be added by "echo `pwd` >> exlist" and that is a one time action too and done in seconds than in minutes.

Again, how many apps are affected?

Not many? - Are we really want to implement that feature for all other apps?

Many? - How will the restore of that backup will be then?

That's not how at least I do backups, however. I want to only backup stuff I can't get elsewhere,

Your arguments do not fit together. You set up a scene with lots of PNDs and plugins manually moved into the right place. If you don't backup that, you will have a lot of manual work again to get your config running.

All the other data is available elsewhere. Restoring a backup should be a very rare occasion. For example, I just checked my home directory size on this computer, and it stands at 187 GiB.

Sure? Thats nothing. Did you ever had a disc failure? Two people in my acquaintances had an instant disc failure. One losing his digitized and post-edited photos he was working five years on, the other one lost digital only media of his marriage and growing up childrens. The first one still have his data "availabe elsewhere" but will need 5 years again to digitize it.

What happens if your source code is gone? What is your data really worth? Sorry if it looks like i'm drifting the topic, i'll be right back. I've learned a lot from those other peoples failures and replace my backup discs every 3 years now. With the travel photos of my parents i'm on 2TB now, which are backuped nightly within 12 minutes via rsnapshot (which uses rsync = check only, no copy if file is same).

I've learned that an instant working restore of a pandora SD card is worth the possible dupes on the backup or of files available elsewhere. The very rare occasion of a restore situation will backfire, while you waste your time gathering the stuff you can get elswhere, just to figure out that website elsewhere was closed two month ago, or your game were removed from the catalog. If i remember my guest episode til level 40 in wow, it took hours on my system until the game was patched uptodate from first installation.

In a normal case, you just about never need to do it.

Anyway, it's all moot. This system is an optional one.

EDIT: Sorry for the tone, I was tired

No problem. As an non-native as you may noticed, i couldn't recognize the tone anyway. If i hit the wrong tone i'm sorry. Don't get me wrong, i don't want to stop that feature at any cost. I tried to show the consequences, so everybody could consider again what he is doing.

 

[double7]

I have now implemented B-ZaR's suggestion in dbp, with an optional flag in config-file to automatically create the rodata directory for packages.

How does it work?e.g.: Play GBA/GBC Emulation:

appdata/

-GBCemu

-com.explusalpha.GbaEmu

-com.explusalpha.GbcEmu

-gpsp

automatically will create

appdata_RO/

-GBCemu

-com.explusalpha.GbaEmu

-com.explusalpha.GbcEmu

-gpsp

Wallys source problem was that the app does not support a seperate configurable static data directory for GRP (Duke3D maps) files outside appdata. He is "annoyed" because he can't find the savefiles easily.

If the gb emus would have the same problem you still have to put your RO(m) files 4 times onto the SD.

It would be much more useful if the RO mapping could be configured. For the example above all RO dirs should be configurable to point to the one and only RO(m) dir.

The greatest thing would be if more than one RO dir could be configured. If you add a dir which is available while you are connected to your LAN, you could have access to your complete RO files. If you are offline you fall back to the SDcard installed RO files.

That mechanism would help to use smaller SDcards more comfortable, because you don't have to copy a new map to the SD to test it.

 

[slaeshjag]

The implementation I have currently will use two appdata directories if rodata is present, otherwise just appdata. rodata is mounted will less priority than appdata, but with higher priority than the image file. ro-data is not created automatically by default in the conf I currently have in repo, but it could be enabled.

The appdata directories are two separate trees, both have folders for <pkg_id or other name specified in metadata>. Unless per_package_appdata is turned off, then there's no subdirectories for every package.

There seems to be a limitation in aufs that prevents you from unifying with nested sources (eg, /tmp:/tmp/blah won't work.)

Having all the rodata in the same dir for all packages doesn't really make sense if you want to use stuff that isn't emulators. Just having all game data in the same folder would for example be very messy.

I suppose a simple program for creating symlinks and fs unions could fill that gap though, assuming the user uses a file system that supports symlinks. Then you can re-direct ro-data on package level whereever you want.

Though, I guess nothing would stop you from reconfiguring dbp to use <sd-card>/roms/<appdata_name> for ro-data, but that would just be silly...

 

[bzar]

For a quick example, use an application that has plugins and saved state? Put your plugins to the readonly appdata and you can restore the application to with-plugins zero state by deleting its writable appdata.

How can i do that restore if my plugins are in the appdata-ro which is not backed up? If any kind of easy reset functionality is required it should be the task of the app developer to provide savestate or config directories.

That was an example on another use of the system not related to backups. One of the benefits of appdata people have stated is that if you ever want to "reset" your application (after you make a mess of it somehow) is you only need to delete appdata since everything else is read-only inside the PND. WIth the addition of appdata-ro this benefit can be extended to further differentiate between the data that would need to be deleted to reset the application and the data that the PND requires to function. In the case of commercial game PNDs the data you'd put in appdata-ro is actually stuff that would be inside the PND if it wasn't restricted by copyright. Hence appdata-ro can in this case be thought of as a way to extend the PND data instead of providing a place for the user files to exist.

how do you move the RO files to your appdata_RO dir? It means manual action

For new PNDs you may, if you want, put the RO files there in the first place. For existing applications sure, you need to move the files, but it's still less work than coming up with exclude rules and updating scripts. Some people have a LOT of PNDs. You expect them to manually maintain a list of exclude rules?

Yes, i do. I do as you, expect them to take manually actions to achieve their requirements.
And i can't see your difference in first installation or later movement of files. Both are "from source to destination" actions, no matter if you use a gui or cli. The difference is holding another key while mouse movement or typing "mv" instead of "cp".

There's a definite difference in required knowledge for the user. "Copy game files to pandora/appdata-ro/gamename" and "augment your backup script to exclude the file name patterns included in the game data" are very different in terms of complexity. The number of operations may be the same but the complexity is not.
In addition, you need to copy the game data for the games requiring it anyway, so it's just a matter of where you copy it.

I make no assumptions whether the user uses a GUI or a CLI. No idea where that came from

Additionally we forgot something, i think. You have appdata and appdata-ro, but what about the app dir itself? Your real appdata is in appdata/appname, you have appdata-ro and then? How is appdata-ro/appname created?

Do you want to throw all appdata-ro files of all apps into one single appdata-ro dir?

Do you want to manually create appdata-ro/appname for "a lot" of apps?

Do you want auto creation of all appdata/appnames into appdata-ro/appnames?

Do you really think finding the folders via the gui in dozens of empty dirs is less work?

Appdata-ro has the same structure as appdata (as implied by its similar naming). The directory is created by the user if she wishes to have a part of the data there. I don't see the point in automatically creating those directories, since many PNDs won't even need them. For those that do it's the same amount of work as making a subdirectory in the application's appdata directory for the stuff. The cost for the user is neglible at worst.
I don't really understand the finding folders part. It's a better case than with appdata. Every PND has appdata, but only some have appdata-ro. So at worst it's a better case than we already have with appdata.

I think the complexity is even there.

There does not need to be any automatic moving. It's a one-time deal of just putting the RO data to the right place. You'd probably do it by hand in less than five minutes. No need for any scripts to do this. For backupping with excludes you do need scripts since you do it multiple times. In addition you introduce a failing point in your backup system, namely bad exclude rules. One of those might stop important files from being copied. Sure it's easy when you consider a few PNDs, but does the solution scale?

Yes, because it doesn't need scripts as you said. It is one script only and you never touch the script again after it's ready. You would have one exclude file list, which could be added by "echo `pwd` >> exlist" and that is a one time action too and done in seconds than in minutes.

That is if you assume the user does rsync backups (as opposed to just copying the files over which I'd assume is more common since it's simpler) using a script that supports such a file by default. Given that, sure.
The system I'm proposing gives the files implicit semantics based on where they are located. The benefit to differentiating between them for backups is a nice side effect, but the actual thing that happens is dividing the files by their role. It's the same kind of divide as with /usr/bin/foobar, /usr/share/foobar/ and /home/user/.foobar. The binary in /usr/bin/foobar would be the PND, /usr/share/foobar/ would be appdata-ro and /home/user/.foobar would be appdata.

Again, how many apps are affected?

Not many? - Are we really want to implement that feature for all other apps?

Many? - How will the restore of that backup will be then?

That's not how at least I do backups, however. I want to only backup stuff I can't get elsewhere,

Your arguments do not fit together. You set up a scene with lots of PNDs and plugins manually moved into the right place. If you don't backup that, you will have a lot of manual work again to get your config running.

If you want to backup the whole thing, backup the entire pandora directory. It's a balancing act between amount of work on restore and amount of backup space used + amount of backup time used + ease of backup using whatever means you want. The optimal value for this balance varies between users and any scheme intended to ease the backups should not assume any single optimal outcome for it.

All the other data is available elsewhere. Restoring a backup should be a very rare occasion. For example, I just checked my home directory size on this computer, and it stands at 187 GiB.

Sure? Thats nothing. Did you ever had a disc failure? Two people in my acquaintances had an instant disc failure. One losing his digitized and post-edited photos he was working five years on, the other one lost digital only media of his marriage and growing up childrens. The first one still have his data "availabe elsewhere" but will need 5 years again to digitize it.

What happens if your source code is gone? What is your data really worth? Sorry if it looks like i'm drifting the topic, i'll be right back. I've learned a lot from those other peoples failures and replace my backup discs every 3 years now. With the travel photos of my parents i'm on 2TB now, which are backuped nightly within 12 minutes via rsnapshot (which uses rsync = check only, no copy if file is same).

I have more data on a NAS and an offsite server. That was just my home directory on this desktop. I have had several disk failures and have dug SD cards for data using "the sleuth kit" when no backups have been available. My experience has been that it's better to backup what you absolutely must and make sure that is backed up well in several locations on- and offsite. Moving hundreds of GiB worth of mostly readonly data offsite is very time-consuming compared to a few hundred MiB of the actual valuable part.
Pretty much all the data you mention are stuff that would be in the appdata directory. Now consider stuff that you usually get from a software repository. Do you regularly back up your /usr? Because that's pretty much what you're backing up when you backup game files that can't be included in PNDs

I've learned that an instant working restore of a pandora SD card is worth the possible dupes on the backup or of files available elsewhere. The very rare occasion of a restore situation will backfire, while you waste your time gathering the stuff you can get elswhere, just to figure out that website elsewhere was closed two month ago, or your game were removed from the catalog. If i remember my guest episode til level 40 in wow, it took hours on my system until the game was patched uptodate from first installation.

Yes, there are cases where it takes time. If you want instant backup restoration for those cases, you should backup the entire pandora directory anyway, since otherwise you're relying on repo.openpandora.org providing the PNDs back to you. In that case it's all the same if some of the data is in appdata-ro and some in appdata since you're backing them both up alongside the PND directories.

 

[double7]

How can i do that restore if my plugins are in the appdata-ro which is not backed up?

That was an example on another use of the system not related to backups.

And later on you confirmed:

I don't see the point in automatically creating those directories, since many PNDs won't even need them.

At that point we drifted from my question how many apps are really affected by that feature. You know that many won't even need them. Did you add the plugin feature to let the feature look more useful?

One of the benefits of appdata people have stated is that if you ever want to "reset" your application (after you make a mess of it somehow)

You assume that the mess is not related to the RO data or the plugins. I assume that if the user did a mess "somehow" he should better do a reset to a defined state. That is the PND content only.

how do you move the RO files to your appdata_RO dir? It means manual action

For new PNDs you may, if you want, put the RO files there in the first place. For existing applications sure, you need to move the files, but it's still less work than coming up with exclude rules and updating scripts. Some people have a LOT of PNDs. You expect them to manually maintain a list of exclude rules?

Yes, i do. I do as you, expect them to take manually actions to achieve their requirements.
And i can't see your difference in first installation or later movement of files. Both are "from source to destination" actions, no matter if you use a gui or cli. The difference is holding another key while mouse movement or typing "mv" instead of "cp".

There's a definite difference in required knowledge for the user. "Copy game files to pandora/appdata-ro/gamename" and "augment your backup script to exclude the file name patterns included in the game data" are very different in terms of complexity. The number of operations may be the same but the complexity is not.

Add a RO data functionality to the system is as complex than editing a backup script to support exclude files - a user can't do it. I don't see the need for users to do so, slaeshjag added the RO data system and i see no reason why he shouldn't be able to add exclude file support to a backup script.

Do you really think finding the folders via the gui in dozens of empty dirs is less work?

I don't see the point in automatically creating those directories, since many PNDs won't even need them.[...]

For those that do it's the same amount of work as making a subdirectory in the application's appdata directory for the stuff.

The RO function was added because the app did not support subdirectories! If it does, Wally could easily deselect the RO data dir inside the app and copy his savestates only.

I see trouble for users if they need to find the correct appdata dir name between many directories. How should i know that a GB emu is listed at letter "c" because it starts with com.ex... like in my example above? No, it's not that easy as you tell us.

Yes, because it doesn't need scripts as you said. It is one script only and you never touch the script again after it's ready. You would have one exclude file list, which could be added by "echo `pwd` >> exlist" and that is a one time action too and done in seconds than in minutes.

That is if you assume the user does rsync backups

Yes and no. That assumes that the user is annoyed by the way his manual actions became more complicated, just like it happened to Wally. I assume that they will search for an automatic solution then. The already extisting solution for fishing saves only is BGS. Rsync is the extended choice for doing backups with detailed configuration.

Pretty much all the data you mention are stuff that would be in the appdata directory. Now consider stuff that you usually get from a software repository. Do you regularly back up your /usr?

Yes, daily. Because i don't rely that every app will follow the FHS and because i have ~400MB source collection in /usr/local/. If i need a restore, i want it now, complete, instant running again, without hours of recompiling (e.g. in case of slackware). And a restore from local media is way faster than downloading for me. That comfort is worth the ~900MB more backup space and the daily seconds to rsync the /usr content.

 

[bzar]

At that point we drifted from my question how many apps are really affected by that feature. You know that many won't even need them.

It's not relevant how many applications need or are affected by the feature. It does not harm the ones that are not, so it can only make things better. It benefits the ones it benefits.

Did you add the plugin feature to let the feature look more useful?

The plugins were not an added feature, but an example of custom readonly data as opposed to some provided blob of game data. I can think of other examples if you want evidence it's not just an isolated fringe example I made up to make my idea look better. I try to avoid such tactics in conversations as they tend to misrepresent the issue.

One of the benefits of appdata people have stated is that if you ever want to "reset" your application (after you make a mess of it somehow)

You assume that the mess is not related to the RO data or the plugins. I assume that if the user did a mess "somehow" he should better do a reset to a defined state. That is the PND content only.

Let's stop talking about plugins and just call it custom readonly data to avoid making it seem like the nature of the data is anyhow relevant to the benefits of the feature.
Once you add the readonly data and see the application working as intended you can be sure that whatever mess you make after that is related to things in appdata. Now you have two reset points: with custom readonly data (delete only appdata) and bare PND (delete both appdata and appdata-ro). In use cases I can think of it's very unlikely the problem lies within the readonly data. Can you give some examples?

Add a RO data functionality to the system is as complex than editing a backup script to support exclude files - a user can't do it. I don't see the need for users to do so, slaeshjag added the RO data system and i see no reason why he shouldn't be able to add exclude file support to a backup script.

I think there was a misunderstanding at this point. I thought you were suggesting the user to maintain his own script for the backups. Looking at your later text it seems the user only maintains a text file with excluded paths. I was weighing using the appdata-ro system against maintaining a script, not maintaining a text file and using a script.
Still, I do consider it more likely the user will put his files to the correct place than remembers to update a text file after doing so. It's still an extra burden as it adds to the things the user does after copying data to SD. Notice you need to modify the excludes each time you add new stuff to appdata that needs to be excluded. With appdata-ro that information is implicit.

The RO function was added because the app did not support subdirectories! If it does, Wally could easily deselect the RO data dir inside the app and copy his savestates only.

OK, still you do the subdirectory to appdata-ro once, but need to modify the excludes every time you add stuff that needs to be excluded. Say you add such data N times to the card. Of those N times M are cases where you add data to some application you already have at least once. You need to create N - M subdirectories using appdata-ro, but modify excludes N times. Assuming the number of times the user needs to put things in appdata-ro/excludes this difference becomes ridiculously small. I think we should drop both as arguments since they just about balance each other. Even though this decision favors excludes a bit

I see trouble for users if they need to find the correct appdata dir name between many directories. How should i know that a GB emu is listed at letter "c" because it starts with com.ex... like in my example above? No, it's not that easy as you tell us.

Check the appdata for the dir name. It's not that difficult. You have already run the PND once to create the appdata dir anyway, because otherwise you'd have the same exact issue deciding for the name of the appdata directory. You have to find the appdata directory anyway since you'd need to put your data there if not into appdata-ro. The only added step is creating the appdata-ro directory for the PND.
To make this even clearer, see the two work flows below. The first one is using only appdata, the second employing appdata-ro.

Get PND -> Run PND -> Find appdata directory -> Copy data

Get PND -> Run PND -> Find appdata directory -> Create appdata-ro directory for the PND -> Copy data

Yes and no. That assumes that the user is annoyed by the way his manual actions became more complicated, just like it happened to Wally. I assume that they will search for an automatic solution then. The already extisting solution for fishing saves only is BGS. Rsync is the extended choice for doing backups with detailed configuration.

Or you can have appdata-ro and use whatever means you want to just copy appdata over however you want. I'm trying to reduce complexity by adding implicit information here. Generally the solution to fixing issues arising from complex environments is not complex operations, but better organization. By keeping the operations simple you reduce the possibility of errors. Even automation is simpler when the data is well organized.

Pretty much all the data you mention are stuff that would be in the appdata directory. Now consider stuff that you usually get from a software repository. Do you regularly back up your /usr?

Yes, daily. Because i don't rely that every app will follow the FHS and because i have ~400MB source collection in /usr/local/. If i need a restore, i want it now, complete, instant running again, without hours of recompiling (e.g. in case of slackware). And a restore from local media is way faster than downloading for me. That comfort is worth the ~900MB more backup space and the daily seconds to rsync the /usr content.

I think this is a matter where we just have to accept personal preferences. Internet speeds may have something to do with it as well. And you using a distro that requires compiling stuff. Pretty much everything in my /usr can be retrieved in the exact state from arch repositories with just a list of package names (and versions if you don't want to do an upgrade while you're at it). It takes an hour or two, but since I need to do it maybe once in a decade it's not really a big deal. The stuff that matters is mostly in /etc and /home.