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.