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)
Core Graveyard
History: Global
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: wodecki, Unassigned)
References
Details
(Keywords: dataloss, helpwanted)
Attachments
(1 file, 5 obsolete files)
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.
Comment 1•24 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•24 years ago
|
||
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
Comment 3•24 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 7•24 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...
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.
Reporter | ||
Comment 9•24 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)} { ->save_history } run this if clause every time something was added
Comment 10•24 years ago
|
||
Sounds reasonable to me.
Updated•24 years ago
|
Component: History: Session → History: Global
Comment 11•23 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 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.
Reporter | ||
Comment 12•23 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 :-)
Comment 13•23 years ago
|
||
nav triage team: Marking nsCatFood-, if we didn't crash this wouldn't be a problem now would it? ;-)
Keywords: nsCatFood → nsCatFood-
Comment 14•23 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•23 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•23 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•23 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•23 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•23 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
Status: ASSIGNED → NEW
Target Milestone: Future → ---
Comment 20•23 years ago
|
||
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
Updated•23 years ago
|
Target Milestone: --- → Future
Comment 21•23 years ago
|
||
As of Mozilla 0.9.7 a system crash can still wipe out your entire history, at least under Win98.
Comment 22•23 years ago
|
||
fixed by patch in bug 112308.
Status: NEW → ASSIGNED
OS: Linux → All
Hardware: PC → All
Target Milestone: Future → mozilla0.9.9
Comment 23•23 years ago
|
||
fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 24•22 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 Stefan
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 25•22 years ago
|
||
Is this limited to history? I've noticed bookmarks disappearing too.
Comment 26•22 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•22 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•22 years ago
|
||
Did anyone else test this on OS/2?
Updated•22 years ago
|
Target Milestone: mozilla0.9.9 → mozilla1.0
Comment 29•22 years ago
|
||
nsbeta1- per Nav triage team, ->1.2
Comment 30•22 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•22 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 was. Mozilla build 2002040303, WindowsME 4.90.3000
Comment 32•22 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 gone.
Comment 33•22 years ago
|
||
Create a new timer every time the history changes.
Comment 34•22 years ago
|
||
*** Bug 138024 has been marked as a duplicate of this bug. ***
Comment 35•22 years ago
|
||
*** Bug 139551 has been marked as a duplicate of this bug. ***
Comment 36•22 years ago
|
||
It really does not happen very often, but it does happen. pi
Comment 37•22 years ago
|
||
*** Bug 156416 has been marked as a duplicate of this bug. ***
Comment 38•22 years ago
|
||
+1 vote to correct this bug
Comment 39•22 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•22 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•22 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•22 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.
Comment 43•22 years ago
|
||
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•22 years ago
|
||
*** Bug 162621 has been marked as a duplicate of this bug. ***
Comment 45•22 years ago
|
||
+printf("history: sync\n"); remove that. at the very least, wrap it in #ifdef DEBUG
Comment 46•22 years ago
|
||
Removed the printf. I missed it. Also checking better checking of returnvalue.
Attachment #94012 -
Attachment is obsolete: true
Comment 47•22 years ago
|
||
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?
Comment 48•22 years ago
|
||
No, that was not intended. Attaching updated patch.
Attachment #97136 -
Attachment is obsolete: true
Comment 49•22 years ago
|
||
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+
Comment 50•22 years ago
|
||
Same patch, but updated to apply on the current trunk.
Attachment #97195 -
Attachment is obsolete: true
Comment 51•22 years ago
|
||
Do this needs a s= and sr= to check this in?
Comment 52•22 years ago
|
||
it has r= but still needs sr=
Comment 53•22 years ago
|
||
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
Comment 54•22 years ago
|
||
*** Bug 175988 has been marked as a duplicate of this bug. ***
Comment 55•22 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•22 years ago
|
||
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
Comment 57•22 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?
Comment 58•22 years ago
|
||
*** Bug 178635 has been marked as a duplicate of this bug. ***
Comment 59•22 years ago
|
||
*** Bug 178635 has been marked as a duplicate of this bug. ***
Comment 60•22 years ago
|
||
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
Comment 61•21 years ago
|
||
Has anybody seen this problem recently? I haven't for a long time. pi
Comment 62•21 years ago
|
||
I still have it in Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3) Gecko/20030312
Comment 63•21 years ago
|
||
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.
Comment 64•21 years ago
|
||
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•21 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•21 years ago
|
||
Attachment #79283 -
Attachment is obsolete: true
Attachment #98332 -
Attachment is obsolete: true
Attachment #127059 -
Flags: superreview?(alecf)
Comment 67•21 years ago
|
||
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•21 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•21 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•21 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-
Comment 71•21 years ago
|
||
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
Comment 72•21 years ago
|
||
*** Bug 215651 has been marked as a duplicate of this bug. ***
Comment 73•21 years ago
|
||
*** Bug 221797 has been marked as a duplicate of this bug. ***
Comment 74•21 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. FYI xanthian@well.com
Comment 75•21 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•21 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•21 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.
Comment 78•21 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.
Comment 79•21 years ago
|
||
*** Bug 229586 has been marked as a duplicate of this bug. ***
Comment 80•21 years ago
|
||
The problem occurs on WinXP at Mozilla 1.5. It costs me time and energy.
Comment 81•21 years ago
|
||
*** Bug 231919 has been marked as a duplicate of this bug. ***
Comment 82•20 years ago
|
||
Bug 221797 is now fixed, with the solution included in Mozilla 1.6. Please check if it helped with this problem.
Comment 83•20 years ago
|
||
*** Bug 227257 has been marked as a duplicate of this bug. ***
Comment 84•20 years ago
|
||
*** Bug 242207 has been marked as a duplicate of this bug. ***
Comment 85•20 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•20 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, xanthian@well.com
Comment 87•20 years ago
|
||
*** Bug 241841 has been marked as a duplicate of this bug. ***
Comment 88•20 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•19 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•19 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. FWIW xanthian.
Comment 91•19 years ago
|
||
*** Bug 294151 has been marked as a duplicate of this bug. ***
Comment 92•18 years ago
|
||
*** Bug 357657 has been marked as a duplicate of this bug. ***
Comment 93•18 years ago
|
||
Is there any activity concerning this dataloss bug ;) ?
Comment 94•18 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•18 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... xanthian.
Comment 96•18 years ago
|
||
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.
Updated•17 years ago
|
Assignee: bross2 → nobody
Status: REOPENED → NEW
QA Contact: claudius → history.global
Updated•17 years ago
|
Priority: P3 → --
Target Milestone: mozilla1.2alpha → ---
Comment 97•16 years ago
|
||
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?
Comment 98•16 years ago
|
||
(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•15 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.
Blocks: profile-corrupt
Status: NEW → RESOLVED
Closed: 23 years ago → 15 years ago
Resolution: --- → WORKSFORME
Updated•6 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•