Pnd - How Do I Make Some Files Editable (To Appdata)?


jottt

Member
Joined
Oct 28, 2009
Messages
321
Location
Middle of Germany
Cheers!

What I want:

A PND that supplies the full programme.
But some of these files will be edited (not just newly created) from the program. Those files should go to appdata.

Is that possible to accomplish or is the only way to copy the data over by script before starting?
 
Joined
Feb 8, 2009
Messages
1,086
jottt said:
Cheers!

What I want:

A PND that supplies the full programme.
But some of these files will be edited (not just newly created) from the program. Those files should go to appdata.

Is that possible to accomplish or is the only way to copy the data over by script before starting?

I'm very curious as well :)
 
Last edited by a moderator:

cosam

Active Member
Joined
Sep 1, 2008
Messages
703
Location
Netherlands
Website
www.cosam.org
The files have to come from somewhere, so if the app isn't going to create them, you're going to have to copy them with a script. The PND cookbook has some examples. If you have a whole bunch, you can tar them up and extract with the "k" option to avoid overwriting existing files.
 

mcobit

Advanced Member
Joined
Jul 28, 2008
Messages
6,910
Yes, put the files into a folder they are normally not in and remove them from their normal place. The create a script, that checks, if these files are avaiable in appdata (mnt/utmp/yourprogram) and if they are not, copy your files to that place, so they will go to appdata.
 

jottt

Member
Joined
Oct 28, 2009
Messages
321
Location
Middle of Germany
Thanks a lot, this was exactly what I was looking for (The Cookbook-Link) (because the next quewstion would have been: Where do I copy, as link to the sd-folder itself obviously wont work for everyone).

Solved...not perfectly, but well enough ;)
 

skeezix

Internal Development
Joined
Mar 11, 2003
Messages
8,064
Website
www.codejedi.com
The way it 'supposed' to work is when an app tries to edits its data, the new verison of the file goes to appdata, and is used there. It should all just work, invisibly. There seems to be some bugs in aufs (perhaps based if its on FAT and not ext2, or the like) where it sometimes has problems doing that.

Hence, its often wise to just have a "working/" dir in your app, and cd into that on run, and on first run copy in any files (so they appear in appdata) and are fully editable, invisible to the app. aufs works for the appdata overlay, and sometimes works for edit-in-place.

I forget particulars, as I was debugging into that a year or more back, but its been on the side track :(

jeff
 

sebt3

homebrew player (P. & C.)
Joined
Sep 9, 2008
Messages
4,842
Age
40
Location
France
Website
sebt3.openpandora.org
I plan on adding a little feature in pnd_run.sh in HF6 to work around that issue : make visible $APPDATADIR environement variable, so the launch script could create the missing underlying directory using :
mkdir -p $APPDATADIR/missing/dir

allowing you to work around the aufs issue.

In the mean time here is what I do plan to use with audacious (NOT YET TESTED) :
Code:
 APP=audacious
 if [ -z "$APPDATADIR" ];then
     printf "WARNING Guessing APPDATADIR="
     PND=$(sudo losetup -a |grep $APP|sed 's/.*(//;s/)//')
     if [[ "x$PND" = "x" ]];then
         {
             mount|awk '/mmc/{print $3;exit}';
             echo /
         }|while read dir;do
             if [ -d $dir/pandora/appdata/$APP ];then
                 APPDATADIR=$dir/pandora/appdata/$APP
             fi
         done
         echo "$APPDATADIR (wild guess)"
     else
         APPDATADIR=$(echo $PND|sed 's/pandora.*/pandora/appdata/'"$APP/")
         echo "$APPDATADIR"
    fi
 
 fi
 if [ -d "$APPDATADIR" ];then
     # Create the skin direrctory
     mkdir -p $APPDATADIR/share/$APP/Skins
 else
     echo "ERROR: APPDATADIR not found !"
 fi
 

cosam

Active Member
Joined
Sep 1, 2008
Messages
703
Location
Netherlands
Website
www.cosam.org
skeezix said:
The way it 'supposed' to work is when an app tries to edits its data, the new verison of the file goes to appdata, and is used there. It should all just work, invisibly. There seems to be some bugs in aufs (perhaps based if its on FAT and not ext2, or the like) where it sometimes has problems doing that.
Could it be something to do with writing to files right under the mount point vs. those in subdirectories? I seem to remember something along those lines. I've always just played it safe and copied anything that needs to be writable, but it would save a lot of farting about if it worked as advertised.

sebt3 said:
I plan on adding a little feature in pnd_run.sh in HF6 to work around that issue : make visible $APPDATADIR environement variable, so the launch script could create the missing underlying directory using :
mkdir -p $APPDATADIR/missing/dir

allowing you to work around the aufs issue.
Sounds like a decent workaround, but I'd avoid putting it in pnd_run.sh. Some PNDs will end up depending on this feature and you're stuck with it forever, so you're left with the cruft even after the real problem has been solved.
 
Last edited by a moderator:

jottt

Member
Joined
Oct 28, 2009
Messages
321
Location
Middle of Germany
If you are working on it already:

It would be nice if, in case the PXML has the argument-tag empty ("") but still set to ignore it completely. At the moment, pnd_run starts with "-a " in this case, which causes issues sometimes, as pnd_run accepts " " as an argument, but not if "-a" is the last option, as bash cuts of the " ", leaving -a without any option and thus failing to start.

Erm...reads weird....do you understand what I mean? ;)
 

sebt3

homebrew player (P. & C.)
Joined
Sep 9, 2008
Messages
4,842
Age
40
Location
France
Website
sebt3.openpandora.org
SteveM said:
Sounds like a decent workaround, but I'd avoid putting it in pnd_run.sh. Some PNDs will end up depending on this feature and you're stuck with it forever, so you're left with the cruft even after the real problem has been solved.
The APPDATADIR environnement variable is used in the pnd_run script to know what to mount anyway. My only change here is to export it to the launched process. I cant see how pnr_run.sh would do without that anyway so the risk is very limited.

EDIT:
jottt said:
It would be nice if, in case the PXML has the argument-tag empty ("") but still set to ignore it completely. At the moment, pnd_run starts with "-a " in this case, which causes issues sometimes, as pnd_run accepts " " as an argument, but not if "-a" is the last option, as bash cuts of the " ", leaving -a without any option and thus failing to start.

Erm...reads weird....do you understand what I mean? ;)
There is a known bug here which is planned to be fixed in HF6. But if you have no arguments to provide to the application, then dont use the argument tag anyway (your PND will still be able to handle them).

I'm planning a large rewrite, I've already build an automated testing environnement to stop all these breakage I tend to generate. Way more to come now that I'm bond-free (I know I wont break stuff : I can test)
 
Last edited by a moderator:

cosam

Active Member
Joined
Sep 1, 2008
Messages
703
Location
Netherlands
Website
www.cosam.org
sebt3 said:
The APPDATADIR environnement variable is used in the pnd_run script to know what to mount anyway. My only change here is to export it to the launched process. I cant see how pnr_run.sh would do without that anyway so the risk is very limited.
Oh, in that case: forget I said anything ;-)
 
Last edited by a moderator:
Top