Corrupt sqlite places file

[Buzzrr]

A dysfunctional places.sqlite file results in the following:

• Unable to launch URLs from the address bar.
• Instead of the home page, Firefox opens to a blank page.
• Back/Forward buttons are disabled.
• The bookmarks and history of Firefox are missing.
• Browser hangs periodically and “Not responding” error is encountered frequently.
• The URLs are not updated as the user browses through various sites.

Rather than hijacking the Bookmarks gone, reset to default, after upgrade to 2.48b thread by barbaz, I've decided to create this one. This all occurred from switching from v2.40 to 2.47 of SeaMonkey. Then I reverted back to v2.40 and encountered these issues.

Gone through http://kb.mozillazine.org/Locked_or_dam ... ces.sqlite

If your Firefox profile folder includes a "places.sqlite.corrupt" file, one reported fix is to open the Firefox profile folder and, after closing Firefox completely, delete or rename the places.sqlite file and then rename "places.sqlite.corrupt" to "places.sqlite". (If you see any other places.sqlite* files, delete those as well, so that only one places.sqlite file remains.) It is possible that certain security or "cleanup" software (e.g., CCleaner) is causing the places.sqlite file corruption. It is also possible that Firefox was not closed properly, as might happen when your computer loses power with Firefox running, which can cause a corrupt places.sqlite file. Always make sure that you close Firefox properly (e.g., no Firefox processes in the Windows Task Manager) before shutting down the computer.

Unfortunately this didn't resolve the missing history. I do use CCleaner so perhaps this may have caused the issue?
I thought it was because of switching SeaMonkey versions.

Now I find this info in SeaMonkey 2.40 release notes:

Data loss warning: If you use a profile with this or any later version and then try to go back to SeaMonkey 2.0, SeaMonkey will rename your history file to places.sqlite.corrupt and create a new places.sqlite file, effectively resetting your browsing history. This is because the internal format changed and the upgrade process only works in one direction. Additionally, running MailNews with local folders and POP3 mail filters may produce summary files that are not correctly read by previous versions of SeaMonkey. If you decide to go back to a previous version of SeaMonkey, you should delete the .msf files for your local folders and POP3 accounts or repair the folders using the folder properties dialog in order to avoid potential data loss.

History was regained using safe mode but only upon initial opening? Another thing is that the urlbar history is inoperative.
Address bar was regained by renaming places.sqlite and having SeaMonkey regenerate a new one, which of course wipes clean of history & bookmarks!
That's not really a solution

Working on this now for half a day!

[therube]

Well, first thing is to always back up first.

That said...

If you have a backup, then everything should still be valid - in 2.40.

If you don't have a backup, but do have the .corrupt, that .corrupt may be valid in 2.40 - you'd have to check.
(And don't use the original .corrupt, test with a backup of that.)

If you have .json/.jsonlz4 they may be able to restore things, again you're just going to have to test.

Might check with (first) renaming the bookmarkbackups directory (to something like bookmarkbackups.NOT), & testing only using places.sqlite & see if that accomplishes anything.

If not, then try reversing the process.
Rename places.sqlite to places.sqlist.NOT, rename bookmarkbackups.NOT to bookmarkbackups.
Start SeaMonkey & see if it might not automatically import into (the initially non-existent places.sqlite).

Test also in FF.
Maybe FF will get you something back where SeaMonkey won't?


As far as the release notes go, any update at any time has the potential to be not-backwards compatible.
So if you make a backup ahead of time...

[Buzzrr]

If you have a backup, then everything should still be valid - in 2.40.

If you don't have a backup, but do have the .corrupt, that .corrupt may be valid in 2.40 - you'd have to check.
(And don't use the original .corrupt, test with a backup of that.)

So I made another profile and replaced the default places.sqlite file with places.sqlite.corrupt. I then deleted the new default file and removed the extension off of the old corrupted file. The history is readable within this new profile.

Well, first thing is to always back up first...

So if you make a backup ahead of time...

I usually back up files with MozBackup but noticed that haven't since beginning of the year!
I have now backed up what I have although the history only starts with beginning of this month.