Closed Bug 102519 Opened 23 years ago Closed 16 years ago

Global history file being cleared

Categories

(Core Graveyard :: History: Global, defect)

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

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: jmucchiello, Unassigned)

References

Details

(Keywords: dataloss, regression, Whiteboard: TESTCASE WANTED, see bug 63292 before commenting)

Attachments

(3 files)

/bin/bash script fragment to jealously guard history data
1.75 KB, text/plain
Details
of course I forgot to test it (sorry); fixed a typo in previous attach
1.75 KB, text/plain
Details
another bugfix to history-guard script
1.77 KB, text/plain
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.3) Gecko/20010801 BuildID: 2001080110 I have been using the history sidebar to keep track of locations I frequent but am too lazy to bookmark. Today, my history was empty when I launched Mozilla. I assume there is an error in the keep last X days code when dealing with month boundaries. Reproducible: Didn't try Steps to Reproduce: Sorry, don't feel like changing my system date and stopping and start Mozilla a bunch of times.
I notice this too. Linux Build 2001093006. My history is all empty.
Same here with regular 0.9.4 (build 2001091311) on MacOS 9.2.1. I'm not sure if it's related, but a few minutes after midnight I got problems with the location bar. I wasn't able to load any new urls anymor, not even after restarting. The urls were in the history list, but not in the cache (I cleared that the previous day). Since I got stuck, I decided to clear the cache, history and location list. Then I wasn't able to load anything, but I noticed that my historylist wasn't cleared either. I tried rebooting, but that didn't help. I thought I had problems with DHCP, the proxyserver, nameserver or whatever (not the first time they did funky things after midnight), so I waited until the morning. In the morning, it was still the same problem, so it wasn't my ISP. I recreated a new profile, and that seemed to have solved all the problems. Sorry, I deleted my old profile, so I can't investigate it anymore. I guess this is completely unrelated, but when I read these 2 reports. Is it possible that Mozilla did somehting strange with the history ? In these 2 cases it was cleared, in case it got stuck somehow. Weird ... Halloween must have come early this year.
I am using build 2001092306 for linux and my history didn't disappear.
My history seemed a bit wonky on Oct 1st (set to remember for "30 days"), using 2001092603 on Win2k. Marking NEW for investigation.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Actually, this problem may be caused by something else. If the system hangs for any reason (either caused or not caused by Mozilla) and I have to reset the computer, if Mozilla was running, the history file is gone the next time it's launched. I'm not sure it this is a known bug or not but the cause is probably not Oct 1 since I've lost the history file twice since then. It is improper shutdown of mozilla clears the history file.
Target Milestone: --- → Future
I just lost my history file, but I wasn't near any interesting time boundaries; middle of day, etc. I'm unaware of anything unusual I did. For the bitten among us, I'm going to attach a piece of my 'mozilla' script; this piece makes backups of the history file, and restores it when it gets lost. Not a solution of course, but a stopgap to avoid that "lobotomized" feeling.
I saw this today too. My history got cleared (and its not even Nov 1st!).
Windows 2000 SP 2 Build ID: 2001110209 OS->ALL Changing summary from "Launch on Oct. 1 cleared my global history file" to "Global History File being cleared" Since this is also happening lately... not only on Oct 1 Adding dataloss, regression keywords
Keywords: dataloss, regression
OS: Windows ME → All
Summary: Launch on Oct. 1 cleared my global history file → Global history file being cleared
Happened again, this time after a crash of 0.9.5. I was doing something a little funky with the X server (lbxproxy) at the time. The script I attached earlier caught the problem, but it exposed a bug in the script too, which I will presently remedy (does anyone care?).
I seem to be too stupid to make the "Edit" interface in bugzilla's attachment thing work right..
Oops, sorry for yet another spam. My history did *not* get cleared this time, I misdiagnosed the situation.
I now have a history file which will *always* be cleared if it's the history.dat when Mozilla starts up. I've verified that both 0.9.5 and 0.9.6 clear it. I think it must have an entry somewhere which causes the parser to choke, but I don't see anything obviously malformed about the file. I would like to send this history file to someone who can diagnose (1) what is in this file which causes Mozilla to ignore it and (2) how that got in there in the first place. However, I don't want to post it as an attachment for privacy reasons (it's my browsing history, after all). Someone (Blake?) please let me know where I can send it.
Scott McPeak, please attach your history file to this bug.
Blocks: profile-corrupt
Andrew, sorry -- I deleted the file a week ago because it seemed like no one cared. Also, I didn't want to simply attach it for privacy reasons (more a matter of principle than anything else). For what it's worth, the history-clearing thing hasn't bitten me since I switched to 0.9.8.
Bummer, sorry. Are there any objections to resolving this bug as worksforme? It doesn't seem to be a problem anymore.
*** Bug 125360 has been marked as a duplicate of this bug. ***
Objection! ;-) Bug 125360 had someone reported they were still getting this bug very recently. As I noted there, I haven't seen this on W2K despite having a fairly unstable system and getting crashes quite often - I suspect this is because NTFS is more resilient that FAT.
This bug has plagued me ever since 0.9.6. I'm using 0.9.9 now (1.0RCx is a not an option for me because of the broken copy link location) and it's in there. If no one has fixed it, it's probably still in 1.0. Do not close this bug! Unfortunately I can't see a pattern. It happens every 1 or 2 days. I'm using Linux now but I had the bug on Windows, too.
I've done several hours of testing and I think I have some useful info on this bug: 1. I can cause it to occur with the following script about every 2nd time: #!/bin/sh mozilla http://www.heise.de/newsticker/ & mozilla http://www.heise.de/newsticker/ & The bug seems to be caused by 2 (or more) Mozillas starting up at the same time. 2. I have straced Mozilla and in the vicinity of history.dat accesses I don't see anything that looks like locking. To me it looks like both Mozillas are writing history.dat at the same time without any kind of locking which results in a broken history.dat that Mozilla unlinks on the next startup (I can provide such a broken history.dat if desired). An interesting side note: I was not able to provoke the bug by killing 2 Mozillas at the same time. Of course that doesn't mean that writing history.dat at program termination (which I assume is done) is safe, it might just mean the race condition is less likely in this case. I really hope it's just a case of missing file locking on history.dat. That should be easy to fix. I'm really looking forward to a Mozilla without this annoying bug. BTW, my machine is a K6/2-500. On faster machines the bug may be less likely to occur, so using a slower machine might be beneficial to reproducing this bug.
The fix for bug 76431, just in, prevents multiple Mozillas from accessing the same profile. Resolving as duplicate. If this is not a duplicate, reopen. *** This bug has been marked as a duplicate of 76431 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
While bug 76431 solves one case of this bug, it does not solve another. On June 2 my history file became clearer. Windows locked up tight while I was browsing requiring a hard reset. I just noticed on the 3rd that I had no history dating before the reboot. I would love to know how the history file becomes so currupt that it is completely lost. I was using RC2 at the time.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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: normal → critical
*** Bug 209864 has been marked as a duplicate of this bug. ***
Shouldn't this bug be a blocker for 0.9?? It is a critical, very annoying bug. A lot of people would not use Ffox because of this bug. Who wants to lose his history every 2-3 weeks?
Flags: blocking1.8a2?
This bug shouldn't be a blocker for anything. IMHO, the bug should be closed as INVALID because: - there is no recent description of how this happens - it doesn't have reliable test case - it is done BY DESIGN to wipe out history and cache when browser shuts down abnormally, e.g. when crash or hard reset occurs
(In reply to comment #27) > - it is done BY DESIGN to wipe out history and cache when browser shuts down > abnormally, e.g. when crash or hard reset occurs That's a bad design and should be fixed ASAP (though history is not necessarily whiped out on a crash). Though I agree, a better steps-to-reproduce are needed.
I totally agree with Nickolay Ponomarev (comment #28). It should be fixed ASAP. The problem is not only with history, but also with the visited urls in the drop down list and visited links different color.
It is "good design", given current cache implementation and the fact that crash took place. When crash occurs, states of cache, history, etc. are indetermined. So, instead of causing further application instability, all items in question are cleared. Therefore, no "drop down list and visited links different color" are preserved. Actual solution is to fix issue(s) that caused crash in the first place. As it stands now, I still think that this bug is INVALID. (See comment #27 too)
To Haris & others: guys, please refrain from statements such as "this should be fixed asap", it's bad etiquette (we can discuss it in Mozillazine forums if you want). If you want to contribute to this bug, please find a reproducible testcase or submit a patch. As for the history being deleted after a crash, this is bug 63292. To Walter: I see my History being cleared from time to time, without crash happening between (currently using new profile and latest Firefox branch build, which I assume it shares common History backend code with Mozilla Suite). Today, I saw it twice, when I entered a "Vote for this bug" page. My instant thought was "phew, I found a reproducible testcase" but, alas, I proved wrong. Anyway, this bug seems to be real.
Whiteboard: TESTCASE WANTED, see bug 63292 before commenting
*** Bug 242207 has been marked as a duplicate of this bug. ***
Flags: blocking1.8a2? → blocking1.8a2-
Using 20010801 on Windows 20004 SP4 and I've got this bug too, if it ever was a bug! Except with mine, the history will randomly clear itself for no reason. The browser doesn't crash or anything. It'll just be there on one page and gone the next.
(In reply to comment #33) > Except with mine, the history will randomly clear itself for no reason. The > browser doesn't crash or anything. It'll just be there on one page and gone the > next. Same problem here with Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 although it happened with earlier version too - usually a few times a week...
Agreed. This happens at least once a week for me. No crashing involved... I just close Firefox... open it up again... and boom, no dropdown history. It is extremely annoying I must admit. If there was an extension that would at least back up the history.dat file, that would be very helpful until this bug can be tracked down.
Tim: Pike's Bookmarks Backup does it <http://www.extensionsmirror.nl/index.php?showtopic=13>
*** Bug 227257 has been marked as a duplicate of this bug. ***
*** Bug 281144 has been marked as a duplicate of this bug. ***
It still happens to me. A few days sooner the history was gone for me without any interaction. It happened on Firefox 1.5 Beta 1.
Assignee: firefox → nobody
Status: REOPENED → NEW
QA Contact: claudius → history.global
Here is a testcase, where the history file is being cleared and it is reproducable. It was posted by William B. Lurie on the mozilla.support.firefox NG: http://groups.google.com/group/mozilla.support.firefox/browse_thread/thread/fc623141eef99ab3/476b40791aad69bb?q=dropping+list+of+places+visited&lnk=nl& He uses Norton System Networks 2006 and reports: >> BANZAI!!!! I repeated this last test very carefully, and found that >> BEFORE I ran One Button Checkup, my drop-down list had eight >> items in it. AFTER I ran One Button Checkup, they were *GONE*!!!! > And now to drop the other shoe, as it were, I have tested further > and have narrowed down which sections of One Button Checkup in > Norton System Works 2006 cause the drop-down list to disappear. > Either of these two segments will cause it to disappear: > Registry Scan, and Norton Cleanup. So either the Registry scan or Norton cleanup causes the history file of Firefox to longer be available to Firefox (at least in this case). This should be reproducible by others. It looks more like Norton System Works is the culprit than Firefox.
(In reply to comment #40) Further information from William and another poster suggests that there is a setting to have NSW remove browser history. So this may be a false alarm. However many people may be unaware of such features in privacy protection products that they run and complain about the loss of history and cookies and such in Firefox. So please check for such software when you experience such problems.
I have FF 3.0 and although auto-complete shows that my history still exists organize history and history side-bar are always empty except for showing entries accumulated through that windows personal history.
This is WORKSFORME in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1b3pre) Gecko/20081210 Shiretoko/3.1b3pre
The issue reported was resolved at the latest in bug 374945 (implementation of Places). Based on that, and on comment 44, resolving WFM. If you have a testcase for this bug report that applies to current trunk builds, please post the testcase, and re-open.
Status: NEW → RESOLVED
Closed: 23 years ago → 16 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: