I have a Backup which I can’t restore.
I have a Backup which I can’t restore. I do not understand why this is broken because it looks just as any other Backup when opened in 7zip.
I also noticed that Lightning resets to default when a backup restore fails – that is not really good behaviour…
Here is the file https://drive.google.com/file/d/0B40xU-30MxN7STdJcW5NdEk4YzQ/view?usp=sharing
Pierre Hébert could you check it?
]]>(Next Post) All »
D5 Creation
< ![CDATA[
I will have a look at it. I am surprised that it leaves the data in a bad state because in theory everything is prepared and checked in a temporary storage before to be copied to the final place 🙁 Well, that’s an opportunity to fix a bad bug!
]]>
< ![CDATA[
Pierre Hébert
As far as I can see the data is very close to correct: all files I checked had the correct content and all required files and directories are present. That possibly fools the check…
]]>
< ![CDATA[
Has the archive been produced by the app or does it contain modified/generated data?
]]>
< ![CDATA[
Pierre Hébert
it was produced by the app but modified with additional data (a container to be specific)
]]>
< ![CDATA[
How did you guess?
]]>
< ![CDATA[
I also tried to completely generate an archive, but that didn’t load at all. (You might even find the script for that in the archive)
]]>
< ![CDATA[
Lol 🙂 This had to happen!
I haven’t had a look at it yet, but one particular thing that Lightning don’t like is the presence of “directory” entries in archive. Most zip tools automatically introduces them in the archive when recursively zipping a directory. You need to either specify the list of files, or remove these directory entries later.
]]>
< ![CDATA[
There are two issues with the archive (or Lightning):
– the first file in the archive must be “version”. It must be read first
– zip entries with a 0 file size (used to mark directories) should be removed
Other than that the archive looks good.
]]>
< ![CDATA[
So I moved version to the first position and removed all but the toplevel directory entries (same result without them). Now I see an even more fatal crash. I can’t even report it via email, it pops up the google Play reporter. So here is the stacktrace:
java.lang.RuntimeException: An error occurred while executing dolnBackground() at android.os.AsyncTask$3.done(AsyncTask.java:309) at java.util.concurrent.FutureTask.finishCompletion(FutureTask.java:354) at java.util.concurrent.FutureTask.setException(FutureTask.java:223) at java.util.concurrent.FutureTask.run(FutureTask.java:242) at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:234) at java.util.concurrent.ThreadPoolExecutorsunWorker(ThreadPoolExecutor.java: 1113) at java.util.concurrent.ThreadPoolExecutor$Workersun(ThreadPoolExecutor.java: 588) at java.lang.Thread.run(Thread.java:818) Caused by: java.lang.NullPointerException: Attempt to invoke virtual method ‘java.lang.String java.util.zip.ZipEntry.getName()’ on a null object reference at net.pierrox.lightning_launcher.data.a.c(BackupRestoreTool.java:530) at net.pierrox.lightning_launcher.data.a.a(BackupRestoreTool.java:397) at net.pierrox.lightning_launcheractivities.ae.a(BackupRestore.java:560) at net.pierrox.lightning_launcheractivities.ae.dolnBackground(BackupRestore.java: 504) at android.os.AsyncTask$2.call(AsyncTask.java:295) at java.util.concurrent.FutureTask.run(FutureTask.java:237) … 4 more
]]>
< ![CDATA[
I told you Lightning was picky…
In addition, there need to be a “core” and “wallpaper” directory entry before “wallpaper/bitmap.png”, and possibly “fonts” and “widgets_data” too. I was wrong, my bad…
This command works:
rm -f out.zip; ( echo version; echo core; find core -type f; find wallpaper; find widgets_data ) | zip -@ out.zip
(fonts directory omitted, add if needed)
]]>