Talk:Locked or damaged places.sqlite

It wasn't obvious from reading the "Damaged or inaccessible files" section that you will lose your sessions, history and home page. It should explicitly state that, rather than just implying it, especially since Mozilla makes such a big deal about how Firefox 3 uses the history. Tanstaafl 20:32, 1 November 2008 (UTC

No one mentioned losing history after removing the places.sqlite and places.sqlite-journal files and it could be that the history was already lost and previous sessions were not being saved (I removed the symptom on lost sessions since I only saw it reported once). The home page is saved in prefs.js isn't it? (browser.startup.homepage) so it wouldn't be lost by removing the sqlite files. I don't know what was preventing it from being loaded at Firefox startup but I see Firefox starting with a blank page mentioned over and over. Resetting preferences also causes the home page to be reset but we don't make a point of it when we tell people to reset their preferences in Firefox (Safe Mode#Safe_Mode_options_in_Firefox doesn't mention it). Alice 21:52, 1 November 2008 (UTC)

Isn't journaling supposed to deal with crashes and power failures during transactions? If not, why is a journaling file created? Is it using PERSIST journaling mode? See http://www.sqlite.org/pragma.html . I'd check it myself but I'm still using 2.0.0.17. Tanstaafl 20:32, 1 November 2008 (UTC)

I can't answer your questions about SQL journal files since I haven't researched it. I'm just summarizing the solutions posted in the threads I've referenced. Bug 445565 mentions a 0-byte places.sqlite-journal file but I don't know if it had anything to do with the issue discussed in the report. My Firefox 3.0.3 profiles don't include the journal files unless the profile is open (closing the profile removes the journal file). I do have a 0-byte places.sqlite-journal file in my test profile for Minefield 3.1 beta2pre that remains 0-byte, even after adding bookmarks and I have no problems in that profile that I am aware of. Alice 21:52, 1 November 2008 (UTC)

How does a user tell the difference between a damaged and a inaccessible sqlite file? I would have assumed that an inaccessible file could be made accessible (perhaps a permissions or file attributes problem), rather than having to delete it. Tanstaafl 20:32, 1 November 2008 (UTC)

I don't know how to tell if a sqlite file is damaged or just inaccessible but I renamed the section "Damaged sqlite files". A permission problem is mentioned for Linux under the "Other solutions" section. I think there might be an extension to inspect sqlite files (something was mentioned in the other bug report on that) but I didn't look into it. I didn't think it necessary to go into the specifics since I'm just providing fixes, not in-depth explanations. For more background on the article see this topic on the Contributor's forum at support.mozilla.com. Alice 21:52, 1 November 2008 (UTC)