Fix race condition and android bugs resulting in an incomplete/corrupted installation#44
Conversation
…ation This will make sure the www folder is never left in a corrupted state. If it is corrupted, it will always be recreated on app start. Also fixes a race condition with two installations being started concurrently, and interfering with each other's files. For example both would compete over the www_backup folder, and in my app's case, this would always fail the update because I have a lot of files in the app and file system errors would occur.
|
Thanks! I'm not sure that |
|
Well, it is being set to It is then set back to The most important fix here however is that little I think it's a good temporary fix, and unless you want to completely redesign the logic behind installations, it at least made the plugin usable for me and I can now work on deploying my app to the respective stores. Thanks for your work on it! :) |
|
Thank you for all the work :) I am totally agree with the |
|
Merged it. But you are right - I need a better way of handling the rollback. |
This will make sure the www folder is never left in a corrupted state. If it is corrupted, it will always be recreated on app start. See: #43
Also once I added logging, I noticed a race condition with two installations being started concurrently, and interfering with each other's files.
I noticed that two calls were being made to the
installmethod, and because isInstalling was set from within the thread, both installs would start concurrently. See the small fix in UpdatesInstaller.java.The two threads would then compete over the
www_backupfolder, and in my app's case, this would always fail the update because I have a lot of files in the app and file system errors would occur as the two threads were deleting and creating the same files. I believe this was probably the root cause of issue #43, but the strengthening added for that doesn't hurt either.