Closed Bug 467814 Opened 11 years ago Closed 11 years ago

KB article: The bookmarks and history system will not be functional

Categories

(support.mozilla.org :: Knowledge Base Articles, task, blocker)

task
Not set
blocker

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: cilias, Assigned: cilias)

References

()

Details

With bug 414715, we'll get a new product help link from Firefox
(http://support.mozilla.com/1/%APP%/%VERSION%/%OS%/%LOCALE%/places-locked) that
needs to be directed to this article.

The content is already covered in <http://support.mozilla.com/en-US/kb/Bookmarks+not+saved#Bookmarks_file_is_write_protected>, so this is just a matter of moving it to a separate article.

The title is based on the current UI in bug 414715.
Reading through the cause(s) of the bug, the solution at <http://support.mozilla.com/en-US/kb/Bookmarks+not+saved#Bookmarks_file_is_write_protected> is not correct. That solution is to open the file properties, and uncheck the "Read-only" attribute.

The correct solution, AIUI, is the section above it, to rename or delete places.sqlite and import bookmarks.

We should also first suggest closing other apps, that may be accessing places.sqlite.
Cheng, could you have a look at this draft? If we can list programs known to cause this, I would like to add that too. There was also a section in the Bookmarks not saved article about resetting places preferences. I didn't add that.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Also, anyone have objections about the article name?
That's the actual error message right? No objections assuming that's the case.
(In reply to comment #5)
> This probably needs to either incorporate or link to 
> http://support.mozilla.com/en-US/kb/Bookmarks+and+toolbar+buttons+not+working+after+upgrading

Why?
Because the "Bookmarks and toolbar buttons not working after upgrading" article addresses bug 452469 about Norton 360 and possibly other software locking places.sqlite (see bug 414715 #2).  How is deleting or renaming places.sqlite going to help when the file is locked?  As far as I know, that's the solution for a places.sqlite that is damaged or missing essential information.

More here, in my Oct 23 2008 comment in the staging copy:
http://support.mozilla.com/en-US/kb/*Bookmarks+and+toolbar+buttons+not+working+after+upgrading
If that's not the correct solution, then let's get the correct solution in this article, not provide an incorrect solution and link to another article.
Okay, I've added content from that article, as well as a section on exiting other programs.
As I read it, bug 414715 is targeted for Firefox 3.1 and will notify users when the places database is locked ("in use" or temporarily inaccessible).  The notice will include a link to this article  to explain the problem (see  #10  "after talking w/ sdwilsh, it's sounding like there's no feasible solution to the lock scenario except to notify the user. we have no control over the external application, and in the case of norton 360 for example, any new db file we create would also get locked."

If you want to limit this article to covering that notification then I think you should "SHOWFOR" the entire article, starting with the part of the intro that says "Firefox will notify you with a message ...", for Firefox 3.1 

In place of "Firefox will notify you with a message ..." and the rest of the article, Firefox 3.0 users who find this article should see something like "many Firefox functions will not work.  See ((other article)) for a solution." with a link to http://support.mozilla.com/en-US/kb/Bookmarks+and+toolbar+buttons+not+working+after+upgrading 

I'm also not sure that the "Places database file" section on deleting or renaming places.sqlite belongs in this article.  Deleting places.sqlite and allowing Firefox to rebuild the places database is the fix for a damaged or corrupt places.sqlite.  I'm looking at bug 414715 #77 "Corrupt: Recreate the database, import the most recent bookmarks backup. Other: Do not recreate the database, show the notification."

Maybe you can get some clarification on that, to explain what "Other" covers.  Does "Other" include the list of non-corrupt errors in bug 464486  #24 and will the notification cover cases in which places.sqlite  is not detected as "corrupt" but is still damaged in such a way that it needs to be manually deleted and rebuilt?

Nitpick: Under the "Check for incompatible extensions" section, you need to fix the "Exit Firefox completely and end any remaining firefox.exe processes" link since it is going to the other article.
> In place of "Firefox will notify you with a message ..." and the rest of the
> article, Firefox 3.0 users who find this article should see something like
> "many Firefox functions will not work.  See ((other article)) for a solution."
> with a link to
> http://support.mozilla.com/en-US/kb/Bookmarks+and+toolbar+buttons+not+working+after+upgrading 

I've just updated the other article to include the "Places database file" solution.
Moved to KB at:
Tue 23 of Dec, 2008 21:24 EST

- Fixed the anchors
- Added the text for 3.0

zzxc says deleting places.sqlite is a solution, so CCing him.
Status: RESOLVED → VERIFIED
(In reply to comment #12)
> Moved to KB at:
> Tue 23 of Dec, 2008 21:24 EST
> 
> - Fixed the anchors
> - Added the text for 3.0

I added text for Firefox 2, fixed last anchor and made some other edits to the staging copy.

> zzxc says deleting places.sqlite is a solution, so CCing him.

I didn't say it wasn't a solution for the reported symptoms, only that it might not belong in an article that deals with the  "bookmarks and history system will not be functional" notification.  If that notice is only given when places.sqlite is locked (but not when it is corrupt or damaged) then I don't see how deleting the file would solve anything.
Looks good. If there aren't any pressing issues, I think we should post any further discussion in the Contributors forum.
Dietrich, Marco, just to be on the safe side, could the two you have a look at this article?
Looks pretty much ok.

Putting on my "newbie user" hat, the bookmarks.html backup seems odd, because there's no reason given as to why the user would do that, and it's not re-imported in the subsequent steps. Maybe it should be an addendum or something?
"any other programs you are running that you suspect are interfering with your web browsing"

maybe some example of what kind of software could do that... security software, cleanup utilities, database managers...

"(Optional) If you want Firefox to automatically import your bookmarks from an existing bookmarks.html file in the profile folder, instead of from a JSON backup, open the bookmarkbackups folder and remove all bookmarks-(date).json files to another location."

the user can also set browser.places.importBookmarksHTML = true to force restoring from bookmarks.html, simply set the pref and restart browser.
(In reply to comment #17)
> the user can also set browser.places.importBookmarksHTML = true to force
> restoring from bookmarks.html, simply set the pref and restart browser.

that's not at all the desired behavior here, as all tags and annotations will be lost, so should not be added.
sure, should go in the "addendum", since the same issue is raised following optional steps to complete remove all backups...
ok we talked on irc, have a couple more issues:

1. we need to make a very large notice, before the database recovery section, that if the user can't figure out the lock problem, there's a good chance that they're just going to be hosed again after doing the database deletion and restore that you recommend. if the lock is caused by a security program, then there's a very good chance it'll just re-lock the new db.

2. the bookmarks.html export in step #1 is not even possible, because the db is locked.

3. asking the user to "remove all bookmarks-(date).json files to another location" is a bad idea. especially if it's only to import a bookmarks.html file. instead, should have the user import the bookmarks.html file via the library, after starting up with a clean database (or with whatever was recovered).

here are the basic steps i suggest for the highest probability of recovery from this, assuming they're sure the db isn't just going to be locked still:

1. quit firefox
2. delete the places.sqlite and journal files
3. delete localstore.rdf
3. start firefox. this will restore the most recent backup
4. if the user has some bookmarks.html they want to import, do it at this point, via the library
Are the both of you using Mac? If so, go back to the article and under "Show content customized for:" click on "Windows". I just want to make sure you didn't miss that content.
You need to log in before you can comment on or make changes to this bug.