--private clobers /data/data/[package name]/files directory

[knappador]

The default behavior when upgrading packages is not to clobber directories or delete files that aren't included in the APK, however, this is in effect what happens when updating using --private. It's wrong and I'm trying to figure out where we clobber this directory. AssetExtract.java looks like it's supposed to be working since mkdirs doesn't clobber directories by default.

This is definitely -not- correct in terms of how the rest of Android application development works. I'm investigating a solution because I have live APK's out there that will lose data on update if I don't fix this =)

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[knappador]

I think it's this line 222 in PythonActivity.java

recursiveDelete(target);

Commenting this line only causes a problem if you had a file in an old APK that causes an issue in a new APK. Handling existing files can be done through overwriting them, but nothing can bring back deleted files, so I would like to comment this line and say why. Some user may in the future want a clean slate...though again, they can solve their issue through overwriting files.

IRC convo:

<knapper_tech> Maybe it's THIS LINE  =X
<knapper_tech> XD
<tshirtman> that does ring a bell!
<tshirtman> though it make sense to do that in case a new version get ride of files it that the app doesn't need anymore, and that could cause bugs
<tshirtman> (imagine you accidentaly ship a file with the same name as a python module, i'll get forever imported in place of the real python module)
<tshirtman> of course, you can always delete the app, thoug
<tshirtman> though
<tshirtman> so doing a full cleanup makes sense, i don't think data should be stored in the app dir anyway
<knapper_tech> Think I found the bug
<knapper_tech> tshirtman,   default expectation of the Android developer is to be responsible for files changing between updates
<knapper_tech> I don't know about iOS.  Have to ask Thomas or someone who knows
<knapper_tech> tshirtman, overwriting existing files is -always- a good enough tool to handle this sort of bug
<knapper_tech> clobbering the entire app directory is very heavy handed and as currently set up will delete any files created by the application at runtime
<tshirtman> yes
<knapper_tech> it's counter-intuitive to what you would expect to not be able to use the os.getcwd() as a place to put files
<tshirtman> it is heavy handed, but is it normal to store files here?
<tshirtman> on osx your app can't create files in the app dir, you have a specific dir for these things
<knapper_tech> tshirtman, it's not -recommended-.  Android docs will say to use SQLlite or conf settings
<knapper_tech> well, the good news is that I can build my local apk's without this option
<knapper_tech> I'll bring it up in my bug =)
<tshirtman> it's a p4a change, not a kivy one anyway :)
<knapper_tech> yeah

[knappador]

The simplest solution I can come up with to enable us to have a more reliable place to put user_data_dir in Kivy and not to change the deletion of the directory where we unpack private.mp3 is to unpack private.mp3 into a subdirectory of /data/data/[package]/files/ and use /data/data/[package]/files/ as the location of user_data_dir. Simply put, we switch to unpacking all our --private files into /data/data/[package]/files/.private instead of just /data/data/[package]/files/. This change will free up /data/data/[package]/files/ for use as a reliable place to put kivy_user_persistent.

What should we call this directory? I think .private is self-explanatory and will basically never collide.

[denys-duchier]

#350 implements this fix using __kivy_root__ as the name of the subdirectory