Closed Bug 24416 Opened 25 years ago Closed 25 years ago

Crash erases bookmarks

Categories

(SeaMonkey :: Bookmarks & History, defect, P2)

x86
Windows 98

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: mozilla, Assigned: mozilla)

Details

(Keywords: crash)

Mozilla crashed on me today while loading http://superpages.gte.com. No big
deal. Problem is that it took all of my bookmarks with it. When I reopened, all
I had where the "Imported IE Favorites". The rest are gone. Took a look at the
../User50/mozprofile/bookmarks.htm and they are really gone - it is now a zero
byte file. Modified at the exact time of the crash.
Severity: normal → major
Priority: P3 → P2
Target Milestone: M14
Steve, is this our bug or one for Waterson and co.?
I am not able to cause a crash at the right time reliably to create a step by
step to demonstrate this bug. I was able to use the file monitoring utility from
http://www.sysinternals.com to gether the following information about the
bookmark.htm file. It appears that Mozilla rewrites the file everytime you open
a bookmark from the sidebar. Here is what I captured from simply double-clicking
a bookmark in the sidebar:

145	8:05:02 PM	Mozilla	Open
D:\MOZILLA-WIN32\USERS50\MOZPROFILE\BOOKMARKS.HTML	SUCCESS	CREATENEW
REPLACEEXISTING WRITEONLY DENYNONE

146	8:05:02 PM	Mozilla	Seek
D:\MOZILLA-WIN32\USERS50\MOZPROFILE\BOOKMARKS.HTML	SUCCESS	Beginning
Offset: 0

147	8:05:02 PM	Mozilla	Seek
D:\MOZILLA-WIN32\USERS50\MOZPROFILE\BOOKMARKS.HTML	SUCCESS	End Offset: 0

148	8:05:02 PM	Mozilla	Seek
D:\MOZILLA-WIN32\USERS50\MOZPROFILE\BOOKMARKS.HTML	SUCCESS	Beginning
Offset: 0

149	8:05:02 PM	Mozilla	Write
D:\MOZILLA-WIN32\USERS50\MOZPROFILE\BOOKMARKS.HTML	SUCCESS	Offset: 0
Length: 4096

150	8:05:02 PM	Mozilla	Write
D:\MOZILLA-WIN32\USERS50\MOZPROFILE\BOOKMARKS.HTML	SUCCESS	Offset: 4096
Length: 4096

151	8:05:02 PM	Mozilla	Write
D:\MOZILLA-WIN32\USERS50\MOZPROFILE\BOOKMARKS.HTML	SUCCESS	Offset: 8192
Length: 3179

152	8:05:02 PM	Mozilla	Close
D:\MOZILLA-WIN32\USERS50\MOZPROFILE\BOOKMARKS.HTML	SUCCESS	CLOSE_FINAL

My theory is obviously that the Mozilla opens the bookmarks and reads them into
memory and then writes a new file replacing the old one. If the crash happens
right while all the bookmarks are in memory, thus removing them all from memory,
Mozilla goes ahead and writes a new bookmark.htm with 0 bytes.

I guess the question should be, why are bookmarks being rewritten with every
access? This is dangerous and is bound to cause some people to lose hundreds or
thousands of bookmarks.
Adding "crash" keyword to all known open crasher bugs.
Keywords: crash
Robert, slamm sez you should be kissed with this ... :-)
Assignee: slamm → rjc
Target Milestone: M14
Let me take a guess at what is happening.  You actually have bookmarked
"http://superpages.gte.com" right?

Two things:

1) For every top-level URL visited, we check and see if its bookmarked. If it
is, we update the bookmark's "Last Visited" date.

2) Bookmarks.html is only written out on a timer (which fires every 10 or 15
seconds) and only if "dirty".
The superpages were in the default bookmarks. I added nothing, nor removed 
nothing. I just went to the URL - it crashed - bookmarks gone. I did notice that 
bookmark.htm is written every time you follow a link. This was seen with FileMon 
from http://www.sysinternals.com/
If you go to URLs that AREN'T bookmarked, do you ever see bookmarks.html written
out?
Not that I have seen.
Yeah, OK.  I don't believe that bookmarks.html is written out every time you go
to a URL that you have bookmarked.  I believe that bookmarks.html IS written out
with ten seconds after going to a URL that's bookmarked.  (The change, of
course, it to that bookmark's "last modified date".)

So, for example, if you have URL 1 and URL 2 both bookmarked, and you quickly
visit URL1 and then visit URL2, bookmarks.html would be expected to be written
only once. (that 10/15 second window of opportunity).

Anyway, I'll probably write some code to dump bookmarks to an intermediate file
and, if the entire set of operations succeed, then move files around on disk. 
That should help prevent data loss.
Fixed.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
code-level fix. marking VERIFIED. jerry, please reopen if you find eveidence to the contrary
Status: RESOLVED → VERIFIED
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.