Talk:Lost bookmarks

From MozillaZine Knowledge Base
Revision as of 01:19, 6 January 2009 by Alice Wyman (talk | contribs) (Launchy)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

We should scrape some data out of here --Np 10:20, 15 Aug 2005 (PDT) (done) --Np 10:46, 16 Aug 2005 (PDT)

That ref. refers back to this article! AnotherGuest.

I removed the System Restore recovery method since it doesn't restore personal data files such as those stored in the user profile. See Alice 03:11, 14 September 2005 (PDT)

"The simple method -- Automatic searching" (added section)

Added a simple search method. People need simple instructions. I think if they find multiple files, they can deal with deciding which one, but they can't always deal with complicated instructions just to find the file. They find one of many, and it's the wrong one, etc. We just had a Mac user who claims she spent a week searching day and night for her bookmarks, when she could have found them in seconds with a simple file search. [[User:AnotherGuest.|AnotherGuest.]

The first sentence of the article tells you where to look for the bookmarks: Firefox and Mozilla Suite store your bookmarks in the file "bookmarks.html" located in the profile folder and changes you make to your bookmarks are saved in this file.. If you follow the profile folder link, the section Profile_folder#For_Windows_2000_and_XP_users includes information for Windows 2000/XP on how to search hidden files and folders. I think that information on how to search for the bookmarks file belongs as a "Note" in the introduction, if anywhere. Alice Wyman 18:38, 14 March 2006 (UTC).
OK, I incorporated your addition and the part of the Intro having to do with bookmark file location into a new "Background" section. Alice Wyman 19:43, 14 March 2006 (UTC)

You say the file is in the profile folder. There may be more than one folder. Also, there are 6 backup files, not 5. There's "bookmarks.bak". --AnotherGuest.

If there's more than one folder, the user set it up himself with a different name so probably knows what's going on. The article correctly states there are 5 dated backup files.--Np 19:22, 15 March 2006 (UTC)

Locating bookmarks to be recovered

If "profiles.ini" is missing or corrupted or a profile has been deleted, the Profile Manager will not locate the data. Unfortunately, this article relies on it. Running %APPDATA% is much more thorough, but that's not in this article. After every autoupdate there are still quite a few people who don't recover their bookmarks, even from backup files.--AnotherGuest.
I don't see where this article relies on "profiles.ini" or the Profile Manager. You can still find or import the bookmarks files, even if the profiles.ini file is missing or if the profile itself has been removed from the Profile Manager (which removes its entry form profiles.ini), as long as the files in profile folder have not been deleted. The Background section of the article gives a link for Windows 2000/XP users explaining how to show or search hidden files and folders ( that link also explains about using "%APPDATA%") which I think is enough for the purposes of this article. I know you're thinking of those Win2000/XP users who will still have problems locating the profile folder so here's an idea: Under the Restoring bookmarks from backup section under Method 2 we could add a link to this forum post by trolly..... here's te text of the post: Alice Wyman 19:09, 3 August 2006 (UTC)
The fast and easy solution for bookmark recovery (W2K and WXP):

Bookmarks -> Manage Bookmarks -> File -> Import -> From File. Type "%APPDATA%" in the file field and press ENTER. This opens the "Application Data" folder. Go down into Mozilla, then Firefox and finally Profiles. This is the parent folder of your profile. You should see a folder called xxxxxxxx.default with xxxxxxx is any sequence of numbers and characters. Enter this folder, find the bookmarkbackups folder and enter it. Then select the newest or largest file (bookmarks-YYYY-MM-DD.html with YYYY is the year, MM the month and DD the day) and click OK/Open whatever.

I went ahead and added a link to the above forum post under Method 2 (import from backup) Alice Wyman 19:50, 3 August 2006 (UTC)

Doesn't work. If (1) "profiles.ini" is missing, (2) user has changed to a different profile, or (3) (I forget what the 3rd case is), then neither the Profile Manager nor locating the current profile directory will be sufficient to find lost bookmarks. And those are the only two methods that are listed under "Recovering lost bookmarks". Also, I believe neither method will locate backups from the Bookmarkbackup extension. The ONLY way to be sure of locating all bookmarks is to search the whole computer.
The background information does not tell users that they SHOULD search. It just tells them that they can search, and the hint is pretty much negated by later instructions. The background info should just tell users the file names, that they can search for them, and that they can view the files with a browser. Specific search instructions should be later. Searching should also be part of an explicit list of instructions.
I would make changes, but I'm afraid they might just disappear again. I think we need to agree on the changes and the reasons for them.--AnotherGuest.
I still don't understand what "profiles.ini" has to do with it. I renamed my Firefox profiles.ini file then started Firefox. I got the Import Wizard, (told it not to import anything) and then Firefox started with a fresh profile with a new xxxxxxxx.default folder created along side my original folder and a brand new profiles.ini file was generated showing only the new profile I had no problems importing bookmarks by browsing to the original folder profile folder. Where do you see a problem? Alice Wyman 01:51, 8 August 2006 (UTC)
You had no problem importing them, but you won't be able to find them if you follow the instructions given in "Recovering lost bookmarks". And right now we have a lot of people who don't seem to be able to find their bookmarks or the backups.--AnotherGuest.
Instructions on finding the bookmarks are given in the "Background" section, so I tried to make bookmark recovery instructions a bit easier by linking to #Background and made a few other changes. What do you think? Alice Wyman 18:13, 8 August 2006 (UTC)
I would make changes, but I'm afraid they might just disappear again. Any time you edit the KB someone else can make changes. That goes with the territory :-) ....Hopefully the reason given in the summary will explain why, or an explanation will be written here. Alice Wyman 18:18, 8 August 2006 (UTC)


AnotherGuest, you added the following sentence to this section: "Note also that for searching it is not sufficient to check "Show hidden files and folders" in Windows Explorer. You must set this option in the Search box." However, this claim does not appear to hold true on my Windows 2000 system. Please could you or somebody else confirm that this is true on WinXP, and if so, amend this article and the Profile Folder article. (If it really is true for WinXP then that O/S is even more of a bad joke than I had thought....) Cheers --Mozcerize 16:14, 12 July 2006 (UTC)

I can confirm that, on Windows XP, it is not sufficient to select "Show hidden files and folders" in Windows Explorer. If I UNcheck the "Search hidden files and folders" option and search for "localstore.rdf", for example, a Windows search will NOT find the copy in my C:\Documents and Settings\Alice\Application Data\Mozilla\Firefox\Profiles\default.cta folder, even though "Show hidden files and folders" is selected in Windows Folder Options, View tab. If I DO check the "Search hidden files and folders" option, it will find the Application Data copy. I amended this article to add "in Windows XP" after Note also that for searching..... I similarly amended the a Profile folder article. Alice Wyman 14:29, 13 July 2006 (UTC)
Great, thanks Alice. Just out of interest, will WinXP find hidden files if you check the option in the search area but do not have Explorer set up to show hidden files in general? (Is the option in the search area even available if Explorer is not set up to show hidden files in general?) --Mozcerize 14:34, 13 July 2006 (UTC)
If I select "Do not show hidden files and folders" in Windows Explorer Folder Options, View tab (so that the "Application Data" folder does not appear under C:\Documents and Settings\Alice), a Windows search will STILL find the localstore.rdf file in my C:\Documents and Settings\Alice\Application Data\Mozilla\Firefox\Profiles\default.cta folder, as long as "Search hidden files and folders" is checkmarked in the Search window. The options for showing and searching hidden files and folders seem to be independent in Windows XP. Alice Wyman 14:51, 13 July 2006 (UTC)
I notice that it still refers to Win 2000/XP re searching for hidden files. I am reluctant to make changes because I cannot check for Win 2000. My assumption is that it's better to leave a warning that may not apply, rather than omit a warning that does apply.--AnotherGuest. 17 July 2006
Done. --Mozcerize 12:33, 18 July 2006 (UTC)

AnotherGuest, you just changed the article as follows: Windows 2000/XP users will need to enable viewing of hidden files and folders in the Search box itself. This is not true, as was already explained by Mozcerize above, last July (in Windows 2000, it is sufficient to select "Show hidden files and folders" in Windows Explorer, which also enables searching). I think that all this explanation here is unnecessary since the information is already linked here. Alice Wyman 18:46, 19 October 2006 (UTC)

Right. I didn't mean to change the 2000 bit. I'm just tired of going around in circles about this with people who claim exalted status but who skim this section (or not) and can't find a file. So I made it bold and simplified the language a little. Also made it a correct statement -- in Win XP it's not necessary to unhide the directory to find it. Also added back a reference to a simplified search procedure. Some people like to direct people to use %APPDATA%, and it's nice if the existence of the method is mentioned here. AnotherGuest. 19 Oct 06

Title changed

Changed "Recovery procedure if you haven't closed since losing bookmarks" to "Recovery procedure if you haven't closed Firefox since losing bookmarks". I hope I didn't break any links anywhere. I searched, but I'm not sure I did it correctly.--AnotherGuest. 17 July 2006

I changed it again (awhile back) to "Recovery procedure if you have not closed the browser since losing bookmarks" since this article is not just about Firefox but also covers Mozilla Suite/SM. Alice Wyman 14:05, 10 August 2006 (UTC)

Bookmarks lost after computer restart/crash

(Checking for a persistent process subsection)

This recently added section seems to be missing a step or two. I can't make any sense of it, the way it's now written. Here's the content of the section I found confusing, which I removed from the article.
Checking for a persistent process

  1. With Firefox running, open the Windows task manager and switch to the processes tab. Find firefox.exe in the list.
  2. Exit Firefox and watch for firefox.exe to disappear. This may take a few seconds if many tabs were open, or Firefox was using a lot of memory.
    • If the process disappears from the list, you're just seeing Bug 333907. To avoid it, exit Firefox before shutting down your PC
  3. Select firefox.exe in the Task Manager and click on End Process.
    • If the process disappears and doesn't come back you have an extension or plugin issue and should seek support for it (they can usually be fixed by making sure everything is up to date).
    • If the process disappears but comes back, you have a virus, or some other malware. Anti-virus software may not be able to detect it. If yours doesn't, seek support.

I added a simple suggestion (under Prevention) to exit the browser completely before shutting down the computer: Alice Wyman 15:40, 2 November 2006 (UTC)


So not sure if I'm adding to this page properly or not, but removing that section was not the right thing to do. I support users on IRC and go through this many times. The way the page has been rearranged since my edit is now more confusing, and doesn't lead people to the right information as fast as possible. There are two big reasons why people are losing their bookmarks and that is the installer bug and after a crash/restart. This information needs to get to them quickly. Next, in my section on crashes/restarts I explained about persistent processes causing the issue. If someone read that section then they'd understand the subsection about checking for the persistent process. Furthermore the Kill application article I think makes no sense as part of the knowledge base for 1, and for 2 there are steps specific to determining whether or not you have malware left in the section you didn't understand.

The background section has no place in an article about lost bookmarks, but in an article about bookmarks themselves, which I also started. When people are missing their bookmarks they want an answer and they want it fast. They don't want a lesson on the history of bookmarks. As someone who does deal with many people experiencing this issue first hand I'm going to revert the page back to my changes. If they're confusing, please make them make more sense, but don't remove them, as they're all necessary for the user to figure out why their bookmarks are going missing, and how to prevent them from going missing in the future.

Majken ^, I see you added back your "Checking for a persistent process" section. It still doesn't make any sense to me. In general, what does it have to do with recovering or preventing lost bookmarks? Specifically, this makes no sense to me:
  1. With Firefox running, open the task manager and switch to the processes tab. Find firefox.exe in the list.
  2. Exit Firefox and watch for firefox.exe to disappear. This may take a few seconds if many tabs were open, or Firefox was using a lot of memory.
    • If the process disappears from the list, you're just seeing Bug 333907.
Why am I seeing that bug if firefox.exe disappears from the processes list after I exit Firefox? Isn't that supposed to happen? Alice Wyman
Alice ^, Bug 333907 is a bug with the way firefox lets windows shut it down. You don't need anything else wrong with your firefox to see this bug. Yes, the process is supposed to disappear, if it doesn't it is an indication something else is wrong that isn't a bug in the browser. The people that see this issue every time they restart their browser, or every time they update firefox most likely have some sort of problem that is causing the firefox.exe process to stick around when it's supposed to disappear.--Majken 23:44, 6 November 2006 (UTC)

Sorry, section is not correct as written

The response notwithstanding, this section needs major revision. The information needs references, and steps and conclusions, as written, are nonsensical.

  • If I carry out steps 1 and 2, the process disappears from the list, and I can guarantee I am not seeing that bug. It's perfectly normal.
  • Step 3 requires that it is still running, but it was closed in step 2.
  • Step 3. "If the process disappears and doesn't come back you have an extension or plugin issue...." If I do this, the process disappears, and I can guarantee I don't have an extension or plugin issue.
  • Step 3: " have an extension or plugin issue...." Maybe. Interesting theory, but I can't verify it. At a minimum it needs some qualification and a reference. Definite statements should be reserved for certainties.
  • "This can be caused by a faulty or misconfigured plugin or extension, or even malware. To see if this is your problem,...." That covers a lot of possibilities. Are you sure this is guaranteed to be a definitive, or even a valid test? Such a broad statement requires at least a reference.

--AnotherGuest. 18 Dec 06

Of course, I agree; moreover, Majken/Lucy has never offered any evidence, not even a reference to a comment in a forum thread or bug report, to substantiate that lost or missing bookmarks are related to shutting down Windows normally with Firefox running. Bug 333907 makes no mention of bookmarks, only a passing comment by Majken about ".rdf failure". She also made a similar comment in bug 319196 on localstore.rdf corruption in which she says that the localstore.rdf issue is also caused by a firefox.exe running process that isn't ended, possibly trojan or plugin-related. Since Majken/Lucy is apparently avoiding all these questions, even about the section not making any sense as written, (also brought up by FatJohn and referred to by VanillaMozilla in the forum thread referenced below), the best I can suggest is that you change the Bookmarks lost after computer restart/crash section to at least make some sense, for example, something like:
The bookmarks file may become corrupted after an abnormal operating system shutdown, as might happen after a system crash or power loss, especially on Windows systems [1]. (You can open the bookmarks.html file using "File -> Open File" from the Firefox or Mozilla Suite menu, if you wish to review the contents.) To recover your bookmarks when the contents of the file itself are lost, see Restoring bookmarks from backup below.

If bookmarks are always lost after restarting

This may occur on Windows systems because Firefox (or Mozilla Suite) is not properly shut down before you power down or restart the computer. This can be caused by a faulty or misconfigured plugin or extension, or even malware, causing Firefox to remain in memory after you exit Firefox. To see if this is your problem, perform the following steps:
  1. Use Firefox to browse the web for a while, then open the Windows Task Manager, select the Processes tab and find firefox.exe in the list
  2. Use "File -> Exit" from the Firefox menu to close Firefox. If the firefox.exe process disappears from the list and it doesn't come back (this may take a few seconds if many tabs were open, or Firefox was using a lot of memory) this is normal. If your bookmarks are always missing whenever you restart the computer, you may be seeing bug 333907 which may cause .rdf file corruption and missing bookmarks. To avoid it, exit Firefox before shutting down your PC
  3. If firefox.exe persists in the list of running processes, end the firefox.exe process by selecting it in the Windows Task Manager and clicking "End Process".
    • If the process disappears and doesn't come back, you may have an extension or plugin issue causing Firefox to persist in memory (for example, firefox.exe may remain active after running a Java applet). You should seek support for it (they can usually be fixed by making sure everything is up to date).
    • If the process disappears but comes back, you probably have a virus, or some other malware. Anti-virus software may not be able to detect it. If yours doesn't, seek support. See also Firefox.exe always open.
Like I said before, though, and in my reply to Np under #User orientation, I would rather have the persistent firefox.exe process stuff removed altogether, since it's unsubstantiated as far as causing lost bookmarks .... but lets see what comes out of the other discussion on the "KB Lost Bookmarks article" thread on the forums.. Alice Wyman 16:04, 20 December 2006 (UTC)
Another problem is that this section mixes two concepts: recovery from backups and .rdf corruption. Alice, I think the steps at least make sense now, but they might be in the wrong place. Aren't committees wonderful?
I just noticed that you have fixed that too. Looks good to me. Notice, however, that it's Windows only.
And I guess you're just chucking these sentences?: "The bookmarks file may become corrupted if your computer crashes, especially on Windows systems.[2] To restore your bookmarks, see Restoring bookmarks from backup below."
NO! I just didn't repeat them. I'll add that to my suggested rewrite, for clarity, plus the fact that this applies "on Windows systems". Alice Wyman 23:59, 20 December 2006 (UTC)
Beyond that, the documented link to .rdf corruption is a little weak, as you note. In the bug report Majken wrote, "I've got a whole bunch of rdf failure in the same situation bugs that depend on this fix...." Maybe she has more info on this. Bugzilla can be a little cryptic.
It's awfully hard to know what's happening or to get a clean paper trail for a KB reference. There are all these longstanding bugs like unterminated processes and various files left open. The situation is even murkier if various malware is involved. We don't want to actually leave out info that is likely to help someone, but the case might be stronger if there were a documented link to bookmarks. --AnotherGuest. 20 Dec 06
Yes, but I hate having this stuff put out with no references, which was also one of my complaints about some of the information given out in the firefox.exe always open article... Oh, well. Now, go ahead and fix this article... I would, but I've sworn off it ;-) . P.S. I liked the suggestion in the forum thread to have a condensed version of the various steps and related causes of missing bookmarks "in a nutshell", with links to the more specific information, sort of like the Standard diagnostic - Firefox article has evolved, with the steps in a condensed version and "see below" links for the details. Alice Wyman 23:59, 20 December 2006 (UTC)

Background, Related bug reports section and reordering

Majken, I added back the "Related bug reports" section you removed without explanation. I also added back the "Background" section since it helps place lost bookmarks in perspective. I agree that the details on Windows 2000/XP users finding hidden files and folders is way too specific but if you look earlier on this Talk page, you will see that others find it important. I did see your new Bookmarks article, so if you want to transfer the information there and link to it, I guess that would be OK with me but others may rather keep it here, as is. I also reordered the sections since the article is more about recovering lost bookmarks than anything else and the section on restoring bookmarks from backup should be near the top since it's what most users want and need. Etiology of lost bookmarks is less important to most users, so I placed it under "Causes and prevention" near the bottom, followed by the bug reports, where it makes more sense. Alice Wyman 23:06, 5 November 2006 (UTC)

Followup on recent changes

I've tried to incorporate the recent changes Majken made to the article, while keeping all the information or linking to it. I removed the Background section and moved the contents to the Bookmarks article. I also fixed up the "Checking for a persistent process" section so that it makes sense to me. If my interpretation is wrong, go ahead and correct it. I also made a few other edits, including a "First steps" section, common in KB articles to point out what the user should check first, and placed the sections on multiple profiles and logon accounts and the Firefox 2 installer bug under it. Alice Wyman 13:49, 6 November 2006 (UTC)

I see that Majken reverted my changes on the "Checking for a persistent process" section so, after also discussing that section with her via PM with no resolution, I'm giving up on that, for now I've reverted some of the changes she's make which wiped out valid information and links (also discussed via PM), and I've reordered the article to place the "bookmark recovery" sections at the front of the article, which is what 99% of users care about, in my opinion, when they lose their bookmarks. Alice Wyman 19:33, 6 November 2006 (UTC)


I find it incredibly frustrating that someone is throwing away information because they don't understand it. I'm trying to explain via PM why this information is important, but maybe it should be put here. The part that Alice doesn't understand is the concept that some things cause firefox.exe to keep running after the user has exited the program. This in itself can be a cause of the bookmarks disappearing frequently on crash/restart, and depending on how the process persists can be an indication of a keylogging trojan (see firefox.exe always open)

Next, yes, people care about restoring their bookmarks, but depending on HOW the bookmarks are lost, the solution is different. I had ordered the article as the first 3 headings were the 3 major causes for bookmarks to appear missing, and under each heading are how it happens and what to do about it. Whether or not Alice agrees with my inclusion of the persistant process check at the beginning of the article, there should be a heading of "Bookmarks lost after a PC restart/crash" so that people who do have this happen to them know that following the restoration instructions below is infact the thing they need to be doing. I also believe that for people that his happens to frequently, either they want to know how to stop it from happening again, or they will switch browsers. They're *not* happy to simply restore their bookmarks once a week. I think its irresponsible and unhelpful to not include all this information in an article about "Lost bookmarks." To me this article is about why they go missing and how to fix it in each case. Part of the fix is preventing them from going missing again, otherwise we can fix all crash bugs by simply starting firefox again. If we want an article simply about how to restore a bookmark from a backup then there should be an article titled "Restoring bookmarks from a backup" (which I think is the purpose of the "Importing Bookmarks" article.)--Majken 23:39, 6 November 2006 (UTC)

(copied from PM)
Now for the process issue. Yes, it is supposed to disappear when you exit firefox. That's what steps 1 and 2 are about. If it happens to :you but your firefox process does disappear on exit, then you're hitting the bug referenced,
If by the first "it", you mean firefox.exe and by the second "it" you mean that the bookmarks are lost, That's what I thought, and by the "bug" you mean that Windows doesn't close down Firefox properly when it's open at exit I understand that and all the rest. My point was, as written it wasn't clear... I was trying to fix it so that most people get it...... but the upshot of all this is..... what's really the point of placing all this at the front of the article?
The user still wants to know how to get his bookmarks back. The smart user will read on to find out some of the causes and possible prevention.... which, if it's a "timing" issue as you put it, to make sure Firefox is completely exited before shutting down Windows.... which is given in the Prevention section. The second scenario, the Firefox process reappearing due to malware.... well, unfortunately I suspect (but I could be wrong?) that the users who are most likely to have malware infestations are probably your less knowledgeable users.... those just want get the current problem fixed. But even so, people accessing the internet with unknown malware have more problems than lost bookmarks!
Speaking of solutions, one of the references I added that was wiped out was a link to this Java article section on a hung browser process after running Java applets. It's just as well it's gone since I wasn't really sure if it applies.... is Windows closing a "hung" process (due to a plugin or whatever) any different from Windows closing a running or "active" process? I'm asking because I don't know.
No need to cc me the bug reports, I have my own collection bookmarked and voted for and already get cc on some bookmark-related bugs, including yours on the Firefox 2 installer bug by the way.
I am glad that you pointed out the problem with closing Windows with Firefox running, but that doesn't help when Windows crashes or the power goes out and the bookmarks file gets fragmented (or "corrupted") and lost. Yes, you may be able to identify a couple of causes and point out that properly closing Firefox can help, but when it comes down to it, you will still have users with lost bookmarks and the only thing they care about is getting them back.
Bottom line, put the stuff that everyone who loses bookmarks is going to need at the top, and put the rest anywhere else since the users that want to understand why this is happening will read through the whole article and then go though the bug reports. --Alice Wyman 00:34, 7 November 2006 (UTC)

That is a good reason for moving the "checking for a persistent process" section to the prevention heading, but it's still not a good enough reason to not have a "Bookmarks Missing after PC restart/crash" heading. And I know it doesn't help when windows crashes or the power goes out, which is why I had a "Bookmarks ALWAYS missing after PC restart/crash" section. For the people that it only happens to on a crash, I haven't said much at all. The idea is that if you've got something WRONG with your browser causing an issue, in any other article we would say what it was and advise you to fix it. Again, though I'm fine if that part of the information I added gets moved to the prevention section. What I feel strongly about is the users being able to see the first 3 headings, decide which ones caused their bookmarks to be lost and then to follow the remedy. hundreds upon hundreds of people lose their bookmarks after a restart/crash and I think it makes the most sense to leave that cause as a heading that can be easily picked out of the page contents --Majken 03:30, 7 November 2006 (UTC)

Bookmarks missing from the UI versus lost or corrupt bookmarks file

Majken, I went through bug 333907, the bug on Firefox being closed too abruptly when Windows is shut down (and some its duplicates) which is the bug referenced in the Lost bookmarks#Bookmarks always missing after PC Restart/crash and Lost_bookmarks#Checking_for_a_persistent_process sections. I don't see where this bug specifically applies to lost bookmarks. The bug report mentions that, when Windows exits with Firefox open and Firefox is improperly closed, Firefox thinks that it crashed when it is subsequently restarted, evidenced by an error displayed if using a "session manager" extension or when Firefox 2 initiates the Session Restore feature (doesn't this also occur when you end the firefox.exe process yourself from Task Manager with Firefox running? I seem to recall that it does). I don't see that anyone mentioned lost bookmarks in the "firefox.exe always open" forum thread, which is linked from the Firefox.exe always open article that you added to the "Checking for a persistent process" section, EXCEPT for when a running firefox.exe process causes the Firefox 2 installer bug, an entirely separate issue that does NOT fragment or corrupt the bookmarks.html file, which is what I mean when I talk about bookmarks being lost, as opposed to being merely missing in the open browser's bookmarks list (i.e, "bookmarks missing from the UI"). Alice Wyman 15:38, 9 November 2006 (UTC)

Your comment 20 in the bug 333907 report mentions possible corruption of rdf files (localstore.rdf? It doesn't specify) .... Corruption of the localstore.rdf file can cause the bookmarks to "go missing" in Firefox (but I'm not sure that it actually causes corruption of the bookmarks,html file) so I added that as a "First steps" section and added the related bug report. Does bug 333907 also have anything to do with actual corruption of the bookmarks.html file? Bookmark data loss does happen when Windows crashes or you power off when Firefox is open, according to the related bug reports. The only other issue I see where having firefox.exe running causes lost bookmarks is in the Firefox 2 installer bug, which causes, among other symptoms of a bad install, the bookmarks to be "missing" with Firefox open. These "missing" bookmarks are not really lost, since the bookmarks.html file itself is still intact. Which brings up an important point, the difference between the "First steps" scenarios (wrong profile or logon, Firefox 2 installer bug) and the recovery sections. The first steps are placed at the top of the article to rule out cases where the bookmarks are not really lost, just "missing" from the Firefox user interface. The thrust of the article is "lost" bookmarks (dataloss due to corrupt or deleted bookmarks) requiring that the user restore the bookmarks, e.g., from a current backup or by reconstructing lost file fragments via Chkdsk. Alice Wyman 15:38, 9 November 2006 (UTC)

I also wanted to add some information from bug 289615, Asa's bug report on "bookmark dataloss in abnormal windows shutdown, especially FAT32 systems" and maybe work it into the article, since it applies to bookmark dataloss as well as profile corruption in general.............from Asa's original description:

I haven't figured out exactly what causes the specific dataloss issues, but I can lose bookmarks, other profile data like cookies, or the full profile. Bookmarks and the full profile lossage seems easiest to reproduce. <snip> Steps to reproduce:
1. Set up a Windows install on FAT32
2. Install Firefox (I've tested 1.0 and 1.0.2 and both are affected)
3. Open Firefox and do various browsing activities.
4. Either with Firefox running or shortly after Firefox shutdown, power down the machine.
5. Restart the machine and allow windows to perform the checkdisk function.

d. open profile and find that bookmarks.html and bookmarks.bak are both gone (I've also seen prefs.js and localstore disappear.) User starts up with an empty bookmarks folder and personal toolbar.

In other words, the same issues that can cause bookmarks dataloss (in this case, powering down the computer with Firefox running) can also cause loss of other profile data, including prefs.js and localstore.rdf. Alice Wyman 13:03, 5 December 2006 (UTC)

Related issues

I changed the article section heading "Possible causes of bookmark file corruption" to "Related issues", to apply to both bookmark loss/corruption and bookmarks missing from the UI, and referred to the "Related Bug reports" section for additional causes. Alice Wyman 00:56, 8 December 2006 (UTC)

User orientation

I think we should make this article a bit more user-oriented. There's some excellent info in here that just needs a bit better organization, in my opinion. Why are "first steps" separated from "recovering lost bookmarks"? If some solutions are really good for users, I would think listing them first in a "Recovery" section would be sufficient. Another issue is the names of the sections themselves. A name like "Bookmarks disappear due to corrupt localstore.rdf" wouldn't clue users in that that's the section they should read. Can these sections be reworded so that they describe the symptoms rather than the cause? Thoughts?--Np 05:55, 9 December 2006 (UTC)

This article got tremendous editing during the past month or two and this is the resulting compromise. I included a "First steps" section because those are issues that may result in "missing" bookmarks when the bookmarks.html file itself is intact. The "Recovery" section talks about restoring bookmarks from backup or lost file fragments in cases where the bookmarks file contents are lost due to corruption fragmentation or deletion. The article originally talked about the location of the bookmarks.html file in the profile folder and how to view its contents, in the "Background" section which was later removed when the article was rewritten by Majken. In other words, the article lost its original focus. If you think you can improve it, be my guest :-) Alice Wyman 01:59, 10 December 2006 (UTC)
OK, I understand the separation a bit more now. Still though, a user wouldn't know whether bookmarks.html is still intact when coming to this article, so I'll see what I can move around.--Np 06:00, 10 December 2006 (UTC)
I've made the changes. It looks massive in the change log, but it's just because I moved sections around.
  • Switched the intro to just briefly explain what the article's about. The previous info I think was too technical to help all users, and it's still available later in the article. It also wasn't getting to the point of why the user's there in the first place. The user wants to know how to get the bookmarks back, but may not care about the filename in the profile.
  • Flattened the hierarchy of the article. Each fix is a now top level heading. The headings are also more useful to the user - they can quickly scan the headings to look for something matching what happened to them.
  • Simplified sections. For example, simplified the Firefox 2 problem by using less technical terms ("not detecting processes" vs "not properly closing") and giving users a way to do without messing around in Task Manager (advanced users are still informed that they can use the old method). I think the last point is a good way of doing this articles, explain in detail the easy way, and briefly mention the alternate advanced ways a problem could be fixed. That way, advanced users can choose their method without the noob users getting overwhelmed with strange commands and file names.--Np 06:57, 10 December 2006 (UTC)
I basically left your changes, even though I disagree with moving the "Recovery" sections further down in the article. I did add back some information your removed, like explaining in the Intro where the bookmarks are stored (which links to the bookmarks article that includes the removed "Background" information). I also added back information on increasing the max bookmark backup and browser.bookmarks.max_backups article link plus a few other edits. The one change I really wanted to make but didn't, was removing the section on checking for a persistent process (Majken's addition). The instructions really belong in the Firefox.exe always open article, for one thing. Secondly, I'm still not convinced that a proper Windows shutdown with firefox.exe running causes any bookmark loss. The bug report mentioned, 333907 has nothing to do with missing bookmarks, but is a Session Restore bug. What's more, if restarting the computer with Firefox running or "not responding" (as would happen if a plugin such as Java caused the browser process to remain in memory), then a lot more people who restart the computer with Firefox running whould be reporting this problem (that's the method suggested in the Firefox is already running, but is not responding error message). I don't see lost bookmarks mentioned as a symptom in the Firefox.exe always open article, (you would think it would be listed with the other symptoms) and I saw no mention of lost bookmarks in the linked forum thread, other than a comment about missing bookmarks after installing Firefox 2, which is covered in the section on the Firefox 2 installer issue. Alice Wyman 23:49, 10 December 2006 (UTC)
I also added back the instructions to export bookmarks in the Prevention section which I think is important, especially for Mozilla Suite/SeaMonkey which doesn't include bookmark backups. Even though profile backup is also suggested, exporting bookmarks is easier and is the specific solution to preserving bookmarks from future loss. I didn't really see the reason for removing those instructions other than shortening the article a bit. Alice Wyman 01:31, 11 December 2006 (UTC)
P.S. I just wanted to add that this is going to be my last edit of this article for awhile. I really want to give it a rest and let other people take their turn with it ;-) Alice Wyman 01:54, 11 December 2006 (UTC)
Looks good to me. The info I removed that you readded is fine to be in the article; either I didn't realize it was more helpful for the suite or I trust your opinion on it. Additional information isn't bad as long as it doesn't confuse the issue. Regarding having recovery last, it's my intention that users will read the titles of the other sections to see if they apply, and then use recovery as a last solution. The recovery section won't help users who had the other problems, though users would think it might and might try it first if it were at the start of the article.--Np 03:57, 11 December 2006 (UTC)
Great! I was worried that I was being overly rigid in what I wanted in the article. Regarding the section I object to (on checking for a persistent process) I guess I can go along with leaving it in, since it also falls under Additional information isn't bad as long as it doesn't confuse the issue.. I think this dispute resolution stuff actually works (thanks for the mediation). Alice Wyman 13:09, 11 December 2006 (UTC)

No good -- crucial information is buried

Right in the intro we have unimportant information, such as, "you may have inadvertently logged in as another user", but there is no mention of any backups. The only really crucial information that users should get right up front is that there are backups and it's urgent to recover them before they are overwritten. This information is now buried. --AnotherGuest. 11 Dec 06

Never mind. Fixed AnotherGuest. 11 Dec 06
Mind if I unbold it and make it Firefox-specific?--Np 21:06, 11 December 2006 (UTC)
Moz Suite loses bookmarks but doesn't make backups? Well, OK, whatever. But I really think bold face or something equivalent is crucial. We still occasionally see someone who doesn't discover the backups in time. AnotherGuest.
That's right, Mozilla Suite and SeaMonkey don't make automatic bookmark backups. I've noticed an occasional "bookmarks.html.sbsd.bak" file in my Mozilla Suite or SeaMonkey profile folder but that's from running Spybot Search and Destroy (see this post and this earlier one for details). I'll let you or Np correct the Intro since I've sworn off editing this article for awhile, unless you want me to fix it. By the way, I also noticed that the reference to "Method 2" should be removed from the Lost_bookmarks#Other_methods_of_recovery section, since Np's previous edit removed the "Method 1" (file copy) and Method 2 (file import) headings from the Lost_bookmarks#Restoring_bookmarks_from_backup section. Alice Wyman 12:24, 12 December 2006 (UTC)
I've removed the reference, since there's already a link to Import bookmarks.--Np 15:24, 12 December 2006 (UTC)
Believe it or not, the section on finding bookmarks still had nothing about finding backup files. The section on recovery had extraneous discussion of why they disappeared. Stuff has now been rearranged and put where it belongs. --AnotherGuest. 8 Feb 07

Regarding info present in other articles

I think that the info we have here that's duplicated elsewhere (importing bookmarks, checking for processes) should be left. It's somewhat frustrated for a user, especially noob users, to be bounced between articles to get what they need. In general, if the info isn't too long and if it's a noob-friendly article like this, it should probably stay.--Np 15:24, 12 December 2006 (UTC)

More discussion

Concerning the "dispute" between Alice and Lucy/Majken edits.

Revision of 5 Jan 07

Combined versions of Alice and AnotherGuest., with recent material contributed by Lucy. Please be VERY careful editing, as there is a lot of discussion, compromise, and editing time on this version. I don't guarantee that it's completely free of bloopers, but I don't believe it should have any big ones. Most of it is basically the same previous versions, but rearranged a little.

Main new feature: step-by-step instructions. Please be very careful about editing this section. This section is supposed to be as brief as possible, and easy on the eyes, so people can quickly get through it without being intimidated (I hope). It is supposed to be contain all the essential information needed to direct people to the correct solution as quickly as possible, but ONLY that information. It should also be a help to those with limited vision, so they don't have to read an excessive amount of prose. But most important, the carefully crafted brevity should contribute to clarity. Please honor the request for brevity. If I had more time I'm sure I could find even more economy of words. If it isn't crystal clear, then this section has failed.

Alice's approach was to put more of the step-by-step details in the first section. The advantage of hers is that there is less jumping around. But I tried to minimize jumping around. Once the user finds the appropriate section, a single mouse click will bring them to the detailed section below. The word "below" also tells the users that they will not be taken to another Web page, and this is important. I have previously tried putting terse detail near the tops of articles, but this approach was not well liked. I hope this lightweight introduction will stick.

There's one new approach I decided not to use for now because it has not been reviewed, but I hope it will be revived. I originally had users searching for their bookmarks from the browser file menu. This has two big advantages: (1) it solves the problem of hidden files; (2) it solves the problem of viewing files, without the reader having to read more instructions. I think there are two problem with most approaches: (1) users don't know when they have found the right file; and (2) many users have trouble dealing with hidden files on Windows systems. Computer veterans are the worst about this because they think they don't have to read the directions.

I don't think the version I just posted, or previous versions are very clear on how to find and restore bookmarks, in particular the sections on finding the right profile, and finding the bookmarkbackups folders in those. These sections could still use some simplification.

This may be my last contribution. I will be taking time off. Take good care of the KB.

Sources for this revision:

--AnotherGuest. 5 Jan 07

Nice consolidation. Don't be gone too long :-) Alice Wyman 22:26, 5 January 2007 (UTC)

Whoa! some MAJOR rewriting needed here!! ...haha, just kidding :) ...the 'Finding Your Bookmarks' part, why don't we just suggest an extension...I know, I know, it would be good to be self contained, but we already have to ask people to use the Command window and search their HDD with other things. Watch - one click : ...a 1K extension that open the specific profile folder that you are using and does nothing else. (You could also use NTT, Edit Config Files, Mr Tech, etc...but maybe overkill.) Two clicks and a restart in total and all problems solved. My research shows that this step is the most frustrating part for users. Many are so frazzled by the time that they find/get to the right profile, that they explode, haha. Think about it - 1K ...and that problem solved forever. --Frank Lion 02:16, 6 January 2007 (UTC)
Good idea. I would also suggest a separate application, which has the advantage that users would never actually have to get it working with the browser or worry about updates or conflicts. Better yet, just fix the darned bugs. Moz has given up on them. Yeah, I'm still here, but only for a short time. --AnotherGuest. 7 Jan 07

Discussion of updater bug removed

In theory, users should not see this any more, so I removed the section. Or should they? I'm having second thoughts. Can someone verify? Majken? If it stays, I think we should make it clear updating from what version to what version will show this bug.--AnotherGuest. 22:41, 14 June 2007 (UTC)

They shouldn't see it any more, unless they updated to, which they shouldn't. I think a good thing to do when removing an "obsolete" section is to add it to the talk page with a note why you removed it, just in case someone wonders why that particular issue isn't mentionned.--Np 01:03, 15 June 2007 (UTC)
My thought is that maybe the installer with the bug is part of the old version, not the new version. If this is true, then if they updated from a version that's older than they may still see the bug.--AnotherGuest. 12:38, 15 June 2007 (UTC)
As far as I can tell, the bug is that the new version installer wasn't checking for existing processes.--Np 17:13, 15 June 2007 (UTC)
Just checked my private messages now, just wanted to say I agree with np. The bug is fixed in the installer that comes with so the only way to hit the problem is if someone specifically looks for 2.--Majken 22:59, 29 June 2007 (UTC)

Slight rewording required?

I recently noticed a very experienced Firefox user quote this 'so you must act quickly, before they are all overwritten.' in relation to bookmark backups, to a user who had just created a brand new profile. That 'urgency' quote is only valid when using the same active profile, if the bookmark backups are in an old disused profile (as in this case) then those bookmark backups can sit there forever, without being overwritten.

Not a problem whatsoever, we have busy forums and not a 'dangerous' message to give out anyway. However, when I read this KB article, it doesn't really make that distinction clear, I think. Perhaps that needs clarification?

BTW if you wonder why I don't just edit it myself, I'll be honest, I just can't get used to the Wiki non-ownership side, so I always prefer just to ask or suggest. :) --Frank Lion 19:59, 4 December 2007 (UTC)

Go ahead and edit the article, Frank. No one owns this article. I'll do it, though, if no one else will... maybe add something to the effect that, if you continue to use the profile, the bookmarks will be overwritten ... ? Alice 20:13, 4 December 2007 (UTC)
Done.--AnotherGuest. 22:40, 4 December 2007 (UTC)

Something to watch in Firefox 3

Should probably include mention of bookmarks.postplaces.html now but it can be a bit tricky, and may be subject to changes before final release. The following were extracted from Bug 381216 – prevent bookmarks dataloss when a user goes from Firefox 2, Firefox 3 beta, Firefox 2, and then back to Firefox 3.

with a new profile, on first exit, you should then see bookmarks-YYYY-MM-DD.html in bookmarkbackups (under your profile), and it should match bookmarks.html (if overwrite pref is true) or bookmarks.postplaces.html (if overwrite pref is false).


"False" as default for "browser.bookmarks.overwrite" could cause issues with third-party applications that are set to read bookmarks.html.

I had thought that I had set mine to True, in case I accidentally used Firefox 2 on my profile used with Firefox 3, but in fact it was set to the default False, and so my bookmarks.html had not changed since 2 Dec 2007 and the bookmarks.postplaces.html generated from the SQLITE file is updated everyday as are the backups. DMcRitchie 05:31, 3 February 2008 (UTC)

Should probably include mention of bookmarks.postplaces.html now but it can be a bit tricky and may be subject to changes before final release. I really don't think we need to mention that file in this article since it is basically a Firefox 3 "backup" file that is covered under Lost_bookmarks#Finding_your_bookmarks when we tell people to search for "bookmarks*" to find all files containing bookmarks. People reading this article don't need to know exactly what bookmarks.postplaces.html is used for.... better to include that information in a new bookmarks.postplaces.html article in the Category:Profile contents (Firefox). What we should do (I'll do it) is mention in the bookmarks.html article that, starting with Firefox 3, "bookmarks.html" is no longer used for storing bookmarks and how current it is depends on the "browser.bookmarks.overwrite" preference (bug 381216 c28 explains that setting it to "true" will keep bookmarks.html current by updating it on exit). Alice 14:24, 3 February 2008 (UTC)
"False" as default for "browser.bookmarks.overwrite" could cause issues with third-party applications that are set to read bookmarks.html. Yes, that's mentioned in bug 381216#c37 with the "Launchy" extension as the example (which I don't use). I'm on the fence about how much to include in this article about Firefox 3 since it isn't released yet. Since "False" is the default preference, we could mention that issue in the bookmarks article as affecting Firefox 3 with a link to the browser.bookmarks.overwrite preference article (which also links to the bug report). I think that type of information belongs in either of those two articles, not in this one. Right now browser.bookmarks.overwrite is included in the "restore" section as a "see this article for details" link but I guess we might want ti include a brief warning in the "Prevention" section about not sharing a profile between Firefox 2 and 3 because of the potential for data loss. Alice 16:25, 3 February 2008 (UTC)
"Launchy for Windows" mentioned in that bug is an application, has nothing to do with the "| Launchy" extension. I have used the extension for years and wouldn't create a profile without it . DMcRitchie 15:12, 4 January 2009 (UTC)
My mistake, then. I thought the bug report comment "I use Launchy in Windows" was referring to the Launchy extension. Alice 01:19, 6 January 2009 (UTC)