Closed IzzySoft closed 8 years ago
New database should be copied to some arbitrary filename and then renamed to lacells.db.new. If lacells.db.new exists and is accessible then the backend will close lacells.db, rename it to lacells.db.bak, rename lacells.db.new to lacells.db and then open it.
No fix, as this is the design and documented in the webpage on GitHub for this backend.
OK, I see. But I wonder why simply copying it worked all those years, and now suddenly breaks. So several tools need to be updated: the lacells-creator is, after creating the DB file, simply pushing it to /sdcard/.nogapps
, and "just placing the DB file into the directory for auto-sync" no longer works either.
Yes, it's possible working around it. But not very user-friendly (with things like simply using it with a sync tool being impossible).
Still, good to know. So I'll either revert to a previous version, or adjust my workflow to do everything manually again. I was one of those using a simply sync mechanism: device syncs automatically whenever connected via USB. Now I have to remember to transfer the database manually when a device is connected :(
Maybe you reconsider? Think of the not-so-tech-savvy users :)
I suspect the not-so-tech-savvy users are probably using the on-phone database generation facility. :)
Well, that point goes to you. Still, it would be much easier if one could simply sync the created file.
Btw: Any intentions to fix the adb push
part of lacells-creator then? As that won't work either :) Line 12 in lib/push
then must rather read:
adb push "$LACELLS_DB" /sdcard/.nogapps/lacells.db.tmp
adb shell "mv /sdcard/.nogapps/lacells.db.tmp /sdcard/.nogapps/lacells.db.new"
Well – apart from the fact the target location might need some fine tuning :)
Almost, at least. Reproduced it 5 times now, no exception in between: while the new (replacement)
lacells.db
is still being copied, Local-GSM-Backend tries to open it, fails, and thus deletes it right away, see line 4 of the following logcat:Only work-around is:
Using the latest version (1.4.7) on CyanogenMod 12.1/Android 5.1 here.
May I propose an "exception handler" for that? I could think of e.g. remembering file size and timestamp on successful opening of the database – and then, when "corruption" is detected, compare that with the existing file. If it differs, sleep for .5..2s and check the file again; if size is growing, sleep again until it's no longer growing, then try opening it again. If it still fails, at least retry a few times more (the transfer might be stalled). If it starts growing again, reset the retry-counter. You could even make intervals and max number of retries (for the last step, i.e. how often to retry when the file is no longer growing) customizable.
If you end up really having to delete a corrupted database, at least give the user a clue: not everybody is used to logcat (it even took me a while to figure what's going on and why my network location had stopped working). E.g. placing a notification would be a good idea. You could even consider renaming the file instead of deleting it straight away: if then the transfer completes a little later, one at least could simply rename it back instead of starting over again and again :)
Thanks in advance (and apologies if I sounded grumpy – no grumpyness meant, just a report friendly asking for a fix :)