jscher2000 said
I'm going to be investigating some of this today...
Thank you. If you can collect the .jsonlz4 backups that can't be restored properly, that may help in chasing down structural problems in the user's database and reduce the privacy issues with collecting places.sqlite files. If circular references or missing roots or other issues can be identified and a solution added to the Verify Integrity tool on the Troubleshooting Information page, that would be really, really useful to support!
</blockquote>
Unfortunately .jsonlz4 likely isn't enough, we need to have the sqlite file itself as this is a database issue.
As far as we know at this time, it is caused by a missing root. My guess is the xmarks add-on caused it, but Billy's latest response seems to imply that isn't the case, so it could be something else.
In any case, the current plan is to check the roots whenever we open the database (which we do currently), and re-insert any missing ones (which we don't do currently). That should get everyone fixed again.
Generally most "fixes" do get added to maintenance (aka verify integrity), or migration routines, but in this case, it seems to make sense to do it slightly differently.
''jscher2000 [[#post-73822|said]]''
<blockquote>
I'm going to be investigating some of this today...</blockquote>
Thank you. If you can collect the .jsonlz4 backups that can't be restored properly, that may help in chasing down structural problems in the user's database and reduce the privacy issues with collecting places.sqlite files. If circular references or missing roots or other issues can be identified and a solution added to the Verify Integrity tool on the Troubleshooting Information page, that would be really, really useful to support!
</blockquote>
Unfortunately .jsonlz4 likely isn't enough, we need to have the sqlite file itself as this is a database issue.
As far as we know at this time, it is caused by a missing root. My guess is the xmarks add-on caused it, but Billy's latest response seems to imply that isn't the case, so it could be something else.
In any case, the current plan is to check the roots whenever we open the database (which we do currently), and re-insert any missing ones (which we don't do currently). That should get everyone fixed again.
Generally most "fixes" do get added to maintenance (aka verify integrity), or migration routines, but in this case, it seems to make sense to do it slightly differently.