Closed Bug 251692 Opened 20 years ago Closed 15 years ago

bookmarks file is overwritten by an empty file in a certain mount sequence

Categories

(Firefox :: Bookmarks & History, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: bshishani, Unassigned)

References

Details

(Keywords: dataloss)

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 :-(
Assignee: vladimir → vladimir+bm
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** 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).
OS: Linux → All
Assignee: vladimir+bm → nobody
*** Bug 314328 has been marked as a duplicate of this bug. ***
Keywords: dataloss
Flags: blocking1.8rc1?
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.
Flags: blocking1.9a1+
Flags: blocking1.8rc1?
Flags: blocking1.8rc1-
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → bookmarks
Flags: blocking1.9?
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.
Flags: blocking1.9a1+
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.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → 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.
You need to log in before you can comment on or make changes to this bug.