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

[jottt]

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?

 

[Schnatterplatsch]

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

 

[cosam]

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]

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]

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]

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]

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) :

 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]

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.

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.

 

[jottt]

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]

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:

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)

 

[skeezix]

SteveM -- that is exactly it; I just don't think its supposed to be that way

jeff

 

[cosam]

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 ;-)