Closed Bug 63292 Opened 24 years ago Closed 15 years ago

session additions to global history lost on crash

Categories

(Core Graveyard :: History: Global, defect)

Product:
Core Graveyard
Component:
History: Global
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: wodecki, Unassigned)

References

Details

(Keywords: dataloss, helpwanted)

Attachments

(1 file, 5 obsolete files)

v. 2.4 (because 2.3 bitrotted)
1.20 KB, patch
alecf
: superreview-
Details | Diff | Splinter Review 
heya,

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.
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.

Changed Summary and Made NEW. Hopefully someone will look at this though i
believe Aphrodite on www.mozdev.org does something similar to this.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: on crash the history gets lost → [RFE] Save History file for Crash recovery
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
*** Bug 63963 has been marked as a duplicate of this bug. ***
Forget that last comment, wrong bugnumber, sorry for the spam
Global History --> off to Alec.
Assignee: radha → alecf
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...
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.0
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.
what about something like this:

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

run this if clause every time something was added
Sounds reasonable to me.
Component: History: Session → History: Global
Bug 77514 describes a related but not identical problem that may
or may not be solvable with a single common code change with this
bug.

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.


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
nav triage team:

Marking nsCatFood-, if we didn't crash this wouldn't be a problem now would it? 
;-)
Keywords: nsCatFood → nsCatFood-
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.
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.


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.
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.


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
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
Status: ASSIGNED → NEW
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).

pi
Target Milestone: --- → Future
As of Mozilla 0.9.7 a system crash can still
wipe out your entire history, at least under Win98.

fixed by patch in bug 112308.
Status: NEW → ASSIGNED
OS: Linux → All
Hardware: PC → All
Target Milestone: Future → mozilla0.9.9
Keywords: nsbeta1
fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
My 0.9.9 (Built 2002031114) chrashed today and the Browser lost all the links
from the history since the Browserstart.
OS: OS/2

Stefan
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Is this limited to history?  I've noticed bookmarks disappearing too.
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?
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.
Did anyone else test this on OS/2?
Target Milestone: mozilla0.9.9 → mozilla1.0
nsbeta1- per Nav triage team, ->1.2
Keywords: nsbeta1 → nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.2alpha
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!
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
was.

Mozilla build 2002040303,
WindowsME 4.90.3000
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
gone.
Attached patch Possible fix (obsolete) — — Splinter Review 
Create a new timer every time the history changes.
*** 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.

pi
*** Bug 156416 has been marked as a duplicate of this bug. ***
+1 vote to correct this bug
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.
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
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.
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.
Attached 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?
*** 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
Attached 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?
Attached 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+
Attached patch patch v2.3 (obsolete) — — Splinter Review 
Same patch, but updated to apply on the current trunk.
Attachment #97195 - Attachment is obsolete: true
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.

pi
*** Bug 175988 has been marked as a duplicate of this bug. ***
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.
In Mozilla v1.2 alpha, the bug that last session history is lost on crash, seems
corrected.

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.

Webmaster33
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. ***
*** Bug 178635 has been marked as a duplicate of this bug. ***
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, 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.

pi
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.

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.

        Attachment #79283 -
        Attachment is obsolete: true

        Attachment #98332 -
        Attachment is obsolete: true

    
  

        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?


    
    

    
  
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 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 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.
See
http://lxr.mozilla.org/seamonkey/source/extensions/cookie/nsCookieService.cpp#758

    
    

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

    
    

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

    
    

    
  
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.

FYI

xanthian@well.com


    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
  
Blocks: 19454

    
    

    
  
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.

    
  
No longer blocks: 19454

    
    

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

    
    

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



    
    

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

    
  
Blocks: 231919

    
    

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

    
  
Blocks: failsafe

    
    

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

    
    

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

    
    

    
  
(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?


    
    

    
  
(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, xanthian@well.com

    
    

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

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
(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.

FWIW

xanthian.




    
    

    
  
*** 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 ;) ? 

    
    

    
  
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. :-)

    
    

    
  
(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...

xanthian.



    
    

    
  
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
Status: REOPENED → NEW
QA Contact: claudius → history.global

    
  
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).
Depends on: 382187

    
    

    
  
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.
Blocks: profile-corrupt
Status: NEW → RESOLVED
Closed: 23 years ago → 15 years ago
Resolution: --- → WORKSFORME

    
  
Product: Core → Core Graveyard

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: