session additions to global history lost on crash



19 years ago
10 months ago


(Reporter: wodecki, Unassigned)


(Blocks 2 bugs, {dataloss, helpwanted})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment, 5 obsolete attachments)



19 years ago

I never close my browser (linux boxc running 24/7) and there's a news site I
visit often during my day. However, if mozilla 0.6 crashes sometimes all links
are in the "I-never-surfed-there-before" colour again. I'm sorry if this is a
known issue, I couldn't find anyting in the buglist.

Comment 1

19 years ago
That may be due to a corrupted history file (history.dat). AFAIK I know, Mozilla
saves its history upon quit, and because you crash we never sync the history.dat
on disk. Which is why Mozilla 'forgets' them.

Comment 2

19 years ago
Changed Summary and Made NEW. Hopefully someone will look at this though i
believe Aphrodite on does something similar to this.
Ever confirmed: true
Summary: on crash the history gets lost → [RFE] Save History file for Crash recovery

Comment 3

19 years ago
Actually I think this is a bug not an RFE.  We apparently don't save history
until app shutdown and we should probably be saving it more often (with every
additional item?).  I couldn't find this in existing open reports for History so
I'm updating the the summary to something like it's original state and assigning
to History for evaluation.  I've seen this in recent windows builds.
Assignee: asa → radha
Component: Browser-General → History
QA Contact: doronr → claudius
Summary: [RFE] Save History file for Crash recovery → session additions to global history lost on crash

Comment 4

19 years ago
*** Bug 63963 has been marked as a duplicate of this bug. ***

Comment 5

19 years ago
Forget that last comment, wrong bugnumber, sorry for the spam
Global History --> off to Alec.
Assignee: radha → alecf

Comment 7

19 years ago
we shouldn't save EVERY time we add a url, but something on a timer would
probably be good. I'm imagining every hour or so.. when I implement it, I'll put
the time in minutes in your preferences, and default it to every 60 minutes, if
history has changed since the last time the timer fired. Set it to 0 if you
don't want it to save automatically..

Eventually we should have a "save yourself" Observer topic, so that other
services beyond just history can all save themselves at the same time...
Priority: -- → P3
Target Milestone: --- → mozilla1.0

Comment 8

19 years ago
5-15 minutes sounds more reasonable. by usage, if the user hasn't made more 
than 5 visits you could hold off for a few timer intervals.

Comment 9

19 years ago
what about something like this:

if {(changed added more than X urls) OR (10 minutes passed and at least one url
was added)} {

run this if clause every time something was added

Comment 10

19 years ago
Sounds reasonable to me.


19 years ago
Component: History: Session → History: Global

Comment 11

18 years ago
Bug 77514 describes a related but not identical problem that may
or may not be solvable with a single common code change with this

I suggest the reporter or a maintainer add "dataloss" to the
keywords for this bug, which is one of the criteria justifying
severity "critical", incidently.

Browser "power users" ;-) who depend heavily on history to reduce
redundent browsing time are not likely to be amused to lose either
history.dat in total, or, as reported here, the history for a
session, so probably keyword "nsCatFood" is also justified.


Comment 12

18 years ago
correct, I don't shutdown my machine each eveing, so I have uptimes ~20 days
(only booting for a new kernel). So if mozilla crashes after 5 days usage or so
it's pretty bad. 

Keywords added btw :-)
Keywords: dataloss, nsCatFood

Comment 13

18 years ago
nav triage team:

Marking nsCatFood-, if we didn't crash this wouldn't be a problem now would it? 
Keywords: nsCatFoodnsCatFood-

Comment 14

18 years ago
ok, just to update the current status: I have checked in a timer that goes off
about 10 seconds after the last URL is loaded, that flushes the data to disk. if
it crashes before the timer goes off, then it will probably lose the data since
the previous time the timer went off. ... and in the end, that's too bad. I'm
not going to impact general browsing performance just to make sure a few urls
are saved to global history.

Comment 15

18 years ago
Wiktor, thanks for the help on the keywords.

Paul, the 77514 version of this bug happens when a system crash happens outside
of Mozilla, so fixing "all Mozilla's crashes" (Solving the Halting Problem ;-) )
would still leave a history data loss without a fix for bug 63292 / bug 77514.
I still think it is catfood.

Alex, glad to see you've started to work on these bugs despite your lack of love
for my reporting style; you lost six weeks in your snit to no good purpose.  On
the plus side, the user would _expect_ to lose data in the last few seconds
before a crash, so your timer sounds appropriate.

Comment 16

18 years ago
I had the timer thing in LONG before your tirades :)

However, I think you need to understand that mork uses a journalling mechanism
to ensure minimal dataloss. When I call nsGlobalHistory::Flush() to flush the
current DB to disk, the data is flushed. if the db is corrupt in any other way,
it's kind of out of control of the database. the database really does do its
very best to try to recover from a corrupt file.

Comment 17

18 years ago
OK, then your fix isn't done yet.  The  77514 version requires not just
that you flush the data to the file, but that, like the bookmark file,
the history.dat file be opened, written (here, appended), and closed
with each flush, rather than left open and so much more vulnerable to
system crashes external to Mozilla.  

It is _never_ a good idea to leave a large sequential file open for
longer than it takes to do a write to it, if there are periods of
idleness in between, and in the case of a file large like history.dat
can be, the sheer amount of data loss at risk demands extra care, to
conserve the bulk in preference to the updates, so one trades less
frequent flushes for the overhead of opening and closing the file
each time.

The plan is _always_: accept limited momentary vulnerability, get in,
write, get out, lock down your winnings by returning to a safe state.

I've been working helping people understand this exact problem since
1976, when the input medium was a paper teletype keyboard and the
output medium was magnetic tapes, you may have to trust that I know
whereof I speak.

Comment 18

18 years ago
nav triage team:

Marking future and helpwanted. Nav triage team considers the current timer based
solution acceptable. Keeping open in case some kind soul wants to fix this
problem completely.
Keywords: helpwanted
Target Milestone: mozilla1.0 → Future

Comment 19

18 years ago
reassigning history bugs to new owner - send this bug back to me if it looks
like something I should fix (such as embedding-related architecture issues),
rather than the actual history owner...
Assignee: alecf → blakeross
Target Milestone: Future → ---
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012

The problem got worse. Now with a crash (and the number of those increased
dramatically from 0.9.4 to 0.9.5) the entire histroy is destroyed (not 100% sure
that it always happens, but quite often). That dataloss is serious. So I suggest
setting Severity to major.

At least with every start a backup should be created (in /tmp to save the quota).



18 years ago
Target Milestone: --- → Future

Comment 21

18 years ago
As of Mozilla 0.9.7 a system crash can still
wipe out your entire history, at least under Win98.

Comment 22

18 years ago
fixed by patch in bug 112308.
OS: Linux → All
Hardware: PC → All
Target Milestone: Future → mozilla0.9.9


18 years ago
Keywords: nsbeta1

Comment 23

18 years ago
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 24

17 years ago
My 0.9.9 (Built 2002031114) chrashed today and the Browser lost all the links
from the history since the Browserstart.
OS: OS/2

Resolution: FIXED → ---

Comment 25

17 years ago
Is this limited to history?  I've noticed bookmarks disappearing too.

Comment 26

17 years ago
This should be limited to history.  (Bookmarks may have a similar bug).  It's
difficult to believe this isn't fixed.  I was pretty sure I found and fixed the
cause of the problem, and I tested carefully with positive results.  Is it
possible you weren't ever really idle during your browser session?  We make sure
to commit when you're idle so we don't get a perf hit.  Can someone else test this?

Comment 27

17 years ago
and what is, if the Mozilla cannot idle during the session?
I think, the methode with history flashing during idling is not the right way,
Browser are made tho suf and not to idle.
How long does Mozilla takes to flash the history to the disk.
Crash on Mozilla 2002031104 and all Links since start get lost.

Comment 28

17 years ago
Did anyone else test this on OS/2?  


17 years ago
Target Milestone: mozilla0.9.9 → mozilla1.0

Comment 29

17 years ago
nsbeta1- per Nav triage team, ->1.2
Keywords: nsbeta1nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.2alpha

Comment 30

17 years ago
This sucks big time.  Not only do you loose your data, you loose any record of
where you were when the browser crashed!  At least NS4.x didn't do this!

Comment 31

17 years ago
Also lost the "site-specific icons" that replace the standard "bookmark" icon in
the bookmark list.  I'm not certain that it had been "10 seconds after the last
URL is loaded, that flushes the data to disk" (comment #14), though I thought it

Mozilla build 2002040303,
WindowsME 4.90.3000

Comment 32

17 years ago
The bug is still present in 0.9.9 20020311, on my Windows 98 box. Mozilla leaves
the history open all the time, instead of _opening, writing and closing_.

I was testing another program, with Mozilla open in the background. The program
I was testing crashed, and after reboot, all history, and a bookmark or two, is
Posted patch Possible fix (obsolete) — Splinter Review
Create a new timer every time the history changes.

Comment 34

17 years ago
*** Bug 138024 has been marked as a duplicate of this bug. ***
*** Bug 139551 has been marked as a duplicate of this bug. ***
It really does not happen very often, but it does happen.

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

Comment 38

17 years ago
+1 vote to correct this bug

Comment 39

17 years ago
This bug is still present in 1.0 (Mozilla/5.0 (Windows; U; Win98; en-US;
rv:1.0.0) Gecko/20020530). On my Win 98 machine, if the machine powers down
unexpectedly or hangs and has to be rebooted, ALL history can be lost. It's
happened more than once. Apparently, Mozilla is not _writing then closing_ the
history file. After these types of reboots, Norton Disk Doctor will _invariably_
find lost chains containing remnants of the (now trashed) history.

I recommend upping the severity on this bug.

Comment 40

17 years ago
this happens to me everytime a crash occurs due to a memory corruption on my
windows box or the computer hangs. Upping the severity to Major. If you point me
to the code that I need to change, I'll look at the fixes that need to be made.
Severity: normal → major

Comment 41

17 years ago
This has been working for me on two separate systems (win98, winxp)using nightly
builds over the past several weeks.  And this is with crahses from mozilla
failures to OS failure to a bad memory stick to a system power loss.  And each
time I went back to my history and everything was in tact.  There has to be
something else going on here to cause this inconsistency.

Comment 42

17 years ago
I just did two things on WinXP:

1. Opened Task Manager and executed "End Process Tree" on Mozilla
2. Reset the system (hardware reboot)

Before doing both, I navigated maybe ten pages of information so that the
history could be populated. I have some observations here:

1. There is no loss of information if all the Mozilla windows have been closed
and only Quick Launch is running. (I have turbo mode enabled). I think all the
data is written to the Mozilla rdf files only when all windows have been closed.
And I mean every rdf file that Mozilla writes, including the file that does
address bar autocomplete.

2. If a window is open (for whatever reason) and the browser crashes/is made to
crash/is killed/seg faults or the system reboots without gracefully closing all
browser windows, the data isn't written to the rdf files. 

Now you could say that scenario 2 is by design, iow, you only want to write data
when a window is closed. But that means potentially loss of data is something
goes awry in my OS. IMO, this isn't a very resilient approach.
Posted patch Updated patch (obsolete) — Splinter Review
This patch resets the delay, instead of creating a new timer. The creating of a
new timer did not work correctly, so the history was never written, except when
closing the app.

I could only test it on Linux, can someone else test it on other platforms?

Comment 44

17 years ago
*** Bug 162621 has been marked as a duplicate of this bug. ***
+printf("history: sync\n");

remove that. at the very least, wrap it in #ifdef DEBUG
Posted patch patch v2.1 (obsolete) — Splinter Review
Removed the printf. I missed it.
Also checking better checking of returnvalue.
Attachment #94012 - Attachment is obsolete: true
Hm, I don't really know this code, but you're calling mSyncTimer->Init twice if
it was nsnull: both inside the if, and at the end of your patch.

is that intented?
Posted patch patch v2.2 (obsolete) — Splinter Review
No, that was not intended. Attaching updated patch.
Attachment #97136 - Attachment is obsolete: true
Comment on attachment 97195 [details] [diff] [review]
patch v2.2

r=biesi, though you should probably check if mSyncTymer is non-null after the
CreateInstance and return NS_ERROR_OUT_OF_MEMORY otherwise.
Attachment #97195 - Flags: review+
Posted patch patch v2.3 (obsolete) — Splinter Review
Same patch, but updated to apply on the current trunk.
Attachment #97195 - Attachment is obsolete: true

Comment 51

17 years ago
Do this needs a s= and sr= to check this in?
it has r= but still needs sr=
1) I haven't seen the problem for a long time now.

2) We have a patch which will make things probably even better. There should be
a way to get it in.


Comment 54

17 years ago
*** Bug 175988 has been marked as a duplicate of this bug. ***

Comment 55

17 years ago
Build: 20021021

This happened to me this evening after Mozilla crashed because of the quicktime
plugin on my Win2k laptop. I lost all history for the session, I had some 8 tabs
open in a single window.

Comment 56

17 years ago
In Mozilla v1.2 alpha, the bug that last session history is lost on crash, seems

But the last visited URL is still lost on crash!... It is not stored into history.
It happened, when the crash was occured in middle of a page load.


Comment 57

17 years ago
Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2b) Gecko/20021014

When I have Mozilla in Quicklaunch mode, all history is lost after crashes. When
I have it in non-Quicklaunch mode, history is still present after crashes.

Is this a new bug or part of this one?
*** Bug 178635 has been marked as a duplicate of this bug. ***

Comment 59

17 years ago
*** Bug 178635 has been marked as a duplicate of this bug. ***

Comment 60

17 years ago
By the definitions on <> and
<>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Severity: major → critical
Has anybody seen this problem recently? I haven't for a long time.


Comment 62

16 years ago
I still have it in Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3) Gecko/20030312
Still exists at 1.4 RC3 at Windows. Unpleasant bug - causes dataloss.
If PC is unproperly shut down (electricity source problem), the history is lost.
The way to fix this bug is to go back to using Berkeley DB instead of Mork to
save the history as older Mozilla versions used. Mozilla had to change to the
**** Mork because Berkeley DB was not available on all systems.

No that Berkeley DB is available on all systems is time to move back to 
Berkeley DB and also (possibly) fix bug 17091

This was commented with timeless on irc and the conclusion was that the use of
Mork in Mozilla was inefficient and can cause data loss.

Comment 65

16 years ago
Excuse me but that is *not* what i said. nor was it the conclusion reached by
anyone on irc. it was the pre/mis-conception of the querent.

The conclusion was that the caller sucked. the mork api supports transactions
and the caller chose not to use them. if the caller did the same thing with
another database, the same problem would occur.
a possible fix would be for the history db to be written to disk periodically on
a thread.

Comment 66

16 years ago
Attachment #79283 - Attachment is obsolete: true
Attachment #98332 - Attachment is obsolete: true


16 years ago
Attachment #127059 - Flags: superreview?(alecf)
You said "the mork api supports transactions".
So, why are you not using them instead the **** sync timer.
Why are you not using Berkeley DB?

Comment 68

16 years ago
david reguero: if you have that much of an issue with mork, write a patch
yourself to use berkeley db. The reason we didn't use berkeley DB was not
because of platform porting issues (We've always been very good at that - it
would never be a limitation)

As I recall (and I might be wrong, but I'm closer than the porting issue) the
reason was because it stored data in multiple files (a single history.dat is/was
a requirement) and it did not offer the performance we wanted.

Anyway, stop complaining about mork until you know something about it. Mork is
journal-based and I it isn't an issue of the callers - just calling mork APIs
should result in proper journal format. The problem in this case is that we
don't want the writing of the mork journal to slow down page loading, so we
delay writing to disk until there have been at least 5 (?) seconds of "idle"
(i.e. no pages visited) time.

What we need to do is make global history more tolerant of mork errors - now
that may mean that mork needs to better report journal parsing errors - so that
if the file is read but the last journal entry is corrupt, we still read in the
data. A place to examine this might be the loop in OpenExistingFile() where we
call DoMore() - I'm going to theorize that each call to DoMore() reads in a 
little more of the journal, and that if one of these DoMore()'s fail, there
should be a way to recover the data if any part of the db has been read in....

Comment 69

16 years ago
Comment on attachment 127059 [details] [diff] [review]
v. 2.4 (because 2.3 bitrotted)

and regarding this patch, I used to use this approach, but I ran into platform
issues because not all platforms supported rescheduling of timers - that may
have changed now, but I'm not sure this actually offers any behavioral change
even if rescheduling of timers does work.

Comment 70

16 years ago
Comment on attachment 127059 [details] [diff] [review]
v. 2.4 (because 2.3 bitrotted)

ok, I'm minusing this for now until we get better platform testing.
Attachment #127059 - Flags: superreview?(alecf) → superreview-
Cookies use rescheduling of the timers, and I have not seens any bugreports on
it not working.
*** Bug 215651 has been marked as a duplicate of this bug. ***
*** Bug 221797 has been marked as a duplicate of this bug. ***

Comment 74

16 years ago
Just a note that this bug is alive and well a few years after first
being reported, in MS-Win98SE as of the Mozilla Browser "stable
version 1.4"; I crash this [pathologically fragile OS and hardware]
system fairly often, and have seen the browser history entirely
deleted/corrupted/reset half a dozen times or more in the three
weeks since I downloaded stable version 1.4.

Sorry not to be running a current Mozilla browser test release, but
keeping this platform alive at all is all I can do already without
deliberately running unstable software on it.


Comment 75

16 years ago
Re comment 73: Sorry for filing a dup.
But is bug 221797 really a dup of this bug 63292 ?

The problem described there is a Win9x-(and possibly ME)-only issue: Because the
history.dat file is kept open after flush, the file size in the directory entry
is never updated before closing the file. This does not occur with W2K/XP.

This problem is not addressed by the patches above. For a possible fix see bug
221797 comment 1.

Re comment 74: Kent, I also had the "lost history after crash" problem very
often until I found the recovery method described in bug 113378, comment 10.
Hope this helps.

Comment 76

16 years ago
See dup bug 221797 comment 4 for a demonstration of the Win9x directory flush
issue which causes loss of history.dat on crash. This may be also a problem on
Win2K/XP with FAT file system. Thanks for any comment.

Comment 77

16 years ago
I lost an afternoon of browsing history from a Mozila apllication crash -
(NOT system crash) running under WIN98-SE.
Since recent comments tended towards system crashes, I thought I should mention
that it still happens when the Mozilla application crashes.

I was running the nightly build:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031018
&   Microsoft Windows 98 4.10.2222 A 

Although talkback-enabled - no dump was generated (Which is OK - I can't get
talkback to send the one crash that I do have in anyway! (: )

The BookMarks I'd added shortly before the crash were all OK, so no problem there.


16 years ago
Blocks: 19454

Comment 78

16 years ago
I think that the OS that this bug applies to needs to be changed.  Only ****
OS's being used by hopeless old **** are having this problem apparently.


16 years ago
No longer blocks: 19454

Comment 79

16 years ago
*** Bug 229586 has been marked as a duplicate of this bug. ***

Comment 80

16 years ago
The problem occurs on WinXP at Mozilla 1.5.  It costs me time and energy.

Comment 81

16 years ago
*** Bug 231919 has been marked as a duplicate of this bug. ***


16 years ago
Blocks: 231919

Comment 82

15 years ago
Bug 221797 is now fixed, with the solution included in Mozilla 1.6. Please check
if it helped with this problem.


15 years ago
Blocks: failsafe

Comment 83

15 years ago
*** Bug 227257 has been marked as a duplicate of this bug. ***

Comment 84

15 years ago
*** Bug 242207 has been marked as a duplicate of this bug. ***

Comment 85

15 years ago
(In reply to comment #13)
> nav triage team:
> Marking nsCatFood-, if we didn't crash this wouldn't be a problem now would it? 
> ;-)

Actually it is. I was up 4 days when a tree branch fell on the power lines a
block away. My dumb UPS does not have the required 4 hour capacity to handle
that type of problem. When restarting Moz and opening history, yesterday, 2 days
ago and 3 days ago were all awol. :-(

Does this need to be reassigned to someone who might fix it, or to nobody?

Comment 86

15 years ago
(In reply to comment #85)

> When restarting Moz and opening history, yesterday, 2 days
> ago and 3 days ago were all awol. :-(

I think that's an improvement over the original behavior, when
the entire history became corrupt and went missing (despite
the bug title) IIRC.

> Does this need to be reassigned to someone who might fix it,
> or to nobody?

Since the bug is just a few days short of 3.5 years old, despite
being classified as "critical, data loss", that is a fair question;
the bug is becoming a bit of an embarrassment.

The technology to do two-phase-commit and other robust database
technology operations that preclude data loss has been well known
for decades, but so far no one has bitten off that big an effort
to solve this bug. Meanwhile, the fixes tried have all been of
the "make it less likely to happen" variety rather than the "make
it unable to happen" sort, a wrong approach.

Since the Mozilla project is never going to take over Microsoft
and impose creation of MS-OSen that Just Don't Crash, the onus is
on the Mozilla team to use technology that "just works" _despite_
putrid MS-OS quality, IMAO.

Kent Paul Dolan,

Comment 87

15 years ago
*** Bug 241841 has been marked as a duplicate of this bug. ***

Comment 88

15 years ago
I agree this is really an OS issue (M$ **** file systems), but it needs to be
kludged to workaround the OS.

I've been bit by this numerous times and it always cost me time and effort.

I'd settle for a periodic checkpoint of the DB (as long is it's larger than the
previous DB so we know it hasn't already been zero'd out on restart) and a way
to recover from the most recent checkpoint (like the current DB is smaller than
the checkpointed DB allowing for any history pruning of course).  That way I
could recover to at least a reasonably close history poition.  Last occurence
was on Mozilla 1.7.3 (hasn't crashed yet on 1.7.5) running on XP Pro SP2.

Some thought on the exact algorithm that would include adjusting for any
time-based history pruning would be needed.

Comment 89

14 years ago
This issue seems to be more pervasive then just the global history. Basically
the same thing is happening with the disk cache on OSX. It affects the favicons
which are stored there. I haven't been watching the history but it is probably
caused by the index not being updated when data is written to the disk, the way
the cache is. Why is data being written to the disk without the disk index being
updated? Why is this being considered to be done on a timed interval? It seems
like this can be done for each new page that is loaded; written to the disk
cache, the disk history added, both disk indexes updated, in the background,
while a person views the new page. This should have little affect on performance
since it is done when the browser is mostly idle while the person views. It
would also minimize coruption since the page is stablized while viewing. If the
peron never lets any page completely load you could then kick in the timed function.

Comment 90

14 years ago
(In reply to comment #89)

> Why is data being written to the disk without the
> disk index being updated?  Why is this being
> considered to be done on a timed interval? It
> seems like this can be done for each new page that
> is loaded; written to the disk cache, the disk
> history added, both disk indexes updated, in the
> background, while a person views the new page.
> This should have little affect on performance
> since it is done when the browser is mostly idle
> while the person views.

Unfortunately, that's probably not correct; history
files get pretty massive. I keep mine set at 90 days
so that I don't get a bunch of false "link not
visited" indications, and my history file is a bit
over 25 megabytes. On old hardware, that was a ten
second write task, I'm sure it isn't so bad now, but
perhaps not better by a factor of four yet.

Mozilla needs to live in a multitasking world, and
that much disk activity and the CPU effort to drive
it wouldn't play well with other programs.

Another possibility would be to have a "recent
history", and update that to the main history on
some much less intrusive basis, like once per hour.

The added complexity of working history as two files
wouldn't be much fun, but an hourly history log
probably _could_ be updated efficiently with each
new page.

The recent history could be merged and zeroed if
Mozilla is exited cleanly, or persist just like the
history log if not.

It would also be small enough to allow for a pair of
recent history files, used alternately, so that the
new one could be assured written before the old one
was removed.

I'm wondering if this bug is very high on the list
of "oldest surviving critical bugs in Mozilla"; it
is more than four years old and has resisted all
attempts so far at a bulletproof fix.



*** Bug 294151 has been marked as a duplicate of this bug. ***
*** Bug 357657 has been marked as a duplicate of this bug. ***
Is there any activity concerning this dataloss bug ;) ? 

Comment 94

13 years ago
I now no longer notice this problem to any degree now that I have TabMix+ installed as an extension.  Either I've already read or bookmarked the site, or the "reload evertything that was open at browser crash" functionality in TabMix+ reloads the tab for me...

Of course, it sometimes takes a bit of time to reload 100+ tabs. :-)

Comment 95

13 years ago
(In reply to comment #93)
> Is there any activity concerning this dataloss bug ;) ? 

Not much, read my "reply #90", three ahead of yours,
noting the bug to be four years old. The bug is now
almost _six_ years old, and duplicate reports of it
are still being marked. Fixing history file upkeep
correctly and fully "as loss free as possible" (all
but the last history entry preserved in case of a
cold computer crash to the bare metal) requires
implementing a full "two phase commit" technology,
and implementing it to have sufficient performance
probably would require implementing the history file
as a full blown database for the reasons noted in
reply 90.  Among volunteer labor, no one seems to
want the work effort added to their plate, though
now with freeware RDBMS technology available for
use, the task would be somewhat easier than it would
have been in 12/2000.

On the bright side, the bug used to be a frequent
and horrific problem, now it is very rarely
encountered, so the patchwork fixes done so far have
helped quite a bit.

  Now if someone would only fix all the SeaMonkey
  memory leaks that drag the application to a crawl
  over the course of days of use...


Maybe we are talking on the different things. I mean that if Windows crashes, the file history.dat becomes nulled when the browser starts again. I've had this problem at least once per several months. And the file contains important information and supports convenience when auto typing urls.

I do not know about the realization, but in theory the probability of coincidence of writing to the disk and windows crashing is rather low. So if the suite wrote required data to the disk and flashed buffers, the file could be corrupted in less times.  
Assignee: bross2 → nobody
QA Contact: claudius →


12 years ago
Priority: P3 → --
Target Milestone: mozilla1.2alpha → ---
Now that Firefox3 is saving history using SQLite (Bug 242207) it may be time to close this bug.

Do you have any plans to purge the piece of **** of Mork from Mozilla codebase?
(In reply to comment #97)
> Do you have any plans to purge the piece of shit of Mork from Mozilla codebase?

I expect that will have to wait until bug 382187 "use places for SeaMonkey history" gets fixed. There's work being done on it, but is isn't as easy as snapping one's fingers (or whining on a bug, for that matter).

Comment 99

10 years ago
The issue reported was resolved at the latest in bug 374945 (implementation of Places). 

Resolving WFM.

If you have a testcase for this bug report that applies to current trunk builds, please post the testcase, and re-open.
Last Resolved: 18 years ago10 years ago
Resolution: --- → WORKSFORME


10 months ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.