User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8 The following sequence will cause the bookmarks file to be overwritten with an empty file: Say the 'browser.bookmarks.file' setting is ponting to /shared/bookmarks.html and the file system that contains this file is not yet mounted. Start FireFox, internally FireFox creates an empty bookmark file, the bookmarks menu shows empty. Mount the volume where the bookmarks file is located. Exit FireFox, this causes the empty bookmarks file to overwirte the existing bookmarks file! notes: This bug is related to bug 206567 about deleting symbolic links by FireFox. This bug can commonly occur when users are sharing the bookmarks file between multiple operating systems in a dual boot configuration, or probably sharing it on a network volume. Reproducible: Always Steps to Reproduce: 1.Unmount volume containing bookmarks file 2.Start FireFox 3.Mount volume containing bookmarks file 4.Exit FireFox 5.Bookmarks file is overwritten without any alert Actual Results: old bookmarks file lost Expected Results: 1- alert the user at startup, that a new bookmark file has been created because the default bookmarks file or the one pointed to by 'browser.bookmarks.file' is not accessable for some reason. No action is required here, this is just a dialog box with ok. 2- When a new bookmark file is created in memory, the application should keep a flag, and then when writing the file for the first time, it should be verified that the file does not exist, if it does exist, then this is an unexpected condition, and the user is alerted, and given choices: - to overwrite the file and lose data. - to save the bookmarks file of the current session to some temp file. 3- it would be much better to avoid data loss, that the application keeps a back up copy of the old bookmarks file, as is common in other applications. Bookmark files can be located on network volumes or shared partitions, if the application is making assumptions and acting in silence without alerting the user, it can lead to problems. The application should identify abnormal situations and alert the user. I haven't tested when dierectories in the bookmark file path don't exist, am not sure if FireFox will create these directories without alert.

Looks like a dupe of bug 251456

(In reply to comment #1) > Looks like a dupe of bug 251456 Except this is for Firefox and mine was for Mozilla. Are they regarded as two seperate code bases in this context? If so, there is probably value in maintaining two distinct bugs.

this has nothing to do with the symbolic links bug (Which is fixed for Mozilla). This one is definitely an edge case, but that doesn't mean we shouldn't fix it.

This isn't something we can fix without drastically changing the way we use bookmarks.html. As the file header says, "It will be read and overwritten." -- it was 'read' at startup and found empty. It will later be overwritten; there's no checking to try to detect whether the file was changed outside the process, etc.

it seems that it happens without this mounting trick as well i never saw it in my own eyes but my sister reports that sometimes the firefox starts with the bookmark file completely empty - and her home direcory is on / mount.... she reported it first time with 0.8 and last time it happened yesterday with 0.9.3. unfortunately i can't provide details, she isn't very skilled with computers :-(

Can't you just say, set a variable if firefox failed to load the bookmarks file from the specified location at load time. Then you could either not write out the empty bookmarks file when firefox is closed or at least prompt the user whether they want to overwrite it, or you could check at close time whether the variable I mentioned earlier was set, and if the file now existed and if both conditions were true then take the steps I just mentioned. As it stands handling of the bookmarks file is pretty "dumb".

This problem also occurs if you change the browser.bookmarks.file setting to point to a file that already exists. I keep my bookmarks in a shared location, and was setting up Firefox on a new machine, and my bookmark file was overwritten by the default 'crew picks' etc. The backup file is never any use in these situations, because you restart the browser and find out there's a problem, and once you shut it down both files are overwritten. Luckily I had already made my own backup.

*** Bug 259801 has been marked as a duplicate of this bug. ***

Marking this as OS/All. This bug needs to be updated to reflect that it occurs in more situations that the one the original reporter pointed out (as indicated in comments and in the duped bug).

*** Bug 314328 has been marked as a duplicate of this bug. ***

jesse, can you provide a detailed explanation about why you are nominating this bug to be an RC stopper? Is there something new going on here? Thanks. FYI: the bug that was just duped against this reports a long standing issue that was present in 1.0.x.

I nominated it because I expect the kinds of configurations that can lead to this dataloss to become more common now that Firefox has a better enterprise deployment story.

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change

Just a note to add that USB Flash drives are particularly susceptible to this bug. The steps to loose your bookmark file are the same as outlined in comment #1, except that, with a flash drive, you plug it in, start FireFox (before the drive is ready) and you get a blank bookmark file. Then, upon closing FireFox, it over-writes the (now existing) bookmark file with a blank. Sloppy. With the ever-growing popularity of Flash drives and profiles being kept on them, this should seriously be fixed. A simple check to see it the/a bookmark file exists before save (in instances where FF couldn't find it on launch). Switch one (no file) check on save, type thing.

removed blocking request on extinct 1.9.1a1 flag.

This isn't valid in the new bookmarking system introduced in Firefox 3.0. Since Firefox 2.0 no longer receives support, this bug is INVALID.

Does it also invalidate the issue I mentioned in comment 17, or is that something worth opening a new bug for?

D'oh - I meant comment 7. Please excuse the recursion!

(In reply to comment #18) > D'oh - I meant comment 7. Please excuse the recursion! Yes, that preference no longer exists.