DESCRIPTION: In the past day or two: * all the links that were marked as visited became unvisited * no links that I visited became visited In other words, visited links were no longer indicated. I'm not sure what was happening when the problem started - which build I was running, etc. However, removing the file "history.dat" from ~/.mozilla/David-1/ fixes the problem. I don't want to post that file on Bugzilla, but I can email it to you for debugging. STEPS TO REPRODUCE: * replace ~/.mozilla/<profile-name>/history.dat with the copy I can send you by email (hopefully this is sufficient to reproduce) ACTUAL RESULTS: * no links are ever marked as visited EXPECTED RESULTS: * visited links! DOES NOT WORK CORRECTLY ON: * Linux, mozilla, 2000-03-10-13-M15

[Note to myself: The bad history.dat is currently ~/mozilla/history.dat.bak .]

I noticed this with the 3/10 builds too. Every now and then something changes in a build to cause this to happen. I reopened 27698 because I noticed the Global History window was empty - and no longer recording visited sites. That would of course lead to the same behavior you describe so I guess this is a dupe but these additional symptoms should be reported as well. throwing out .mozilla or creating a new profile is the workaround

cc'ing waterson. Chris, do you own this?

yeah, mine.

dbaron: why don't you go ahead and mail that corrupted history file to me, if you've still got it. cc bienvenu, also. It sounds like it could be a db corruption issue.

Talked with bienvenu. In a private message he reports that there were no obvious signs of corruption in the file, and that "all known sources of corruption have been because [a user was] running two copies of the client against the same profile." Is it possible that this was the case? If the file is not corrupt at the DB level, it could be that global history has somehow horked the data and can't process it properly.

I probably did run two copies of the client against the same profile. Is there a way the behavior when one does that could be improved (or, with X-Remote support, etc., could it be prevented)?

Yeah, this "avoid >1 instance" problem is a known issue. I'm not sure who owns it.

nsbeta2- for the bug with multiple instances of mozilla. please renominate if you can reproduct with one instance of mozilla.

-> rjc

I just found this bug while searching through history related bugs and created the above attachment. I'm running on Linux a fresh build from CVS. I noticed history was not working for 9 days: mtime of the broken history.dat file was September 20. Removing it 'fixed' the problem of global history not working, but of course it is an annoying bug to lose history. As for the usage pattern that caused the corruption, I do not believe, I ever ran two Mozillas against this history.dat, but I cannot preclude it, as it was 9 days or more ago. Please test if this history.dat exhibits the problem for you. It would be a small step forward if the history code could notice the breakage immediately and do something visible like recover fully, recover partially, alert me, panic, whatever.

My visited links don't change color, either. I'm running 2000093020 on Win98SE. My history.dat file was last modified about 3 days ago.

I ran into the same problem on Windows 98. My history file had been last modified around October 4th. Removing the file made visited links start working again.

I've seen this problem a number of times recently. I think it happens whenever I do something like: * start up instance A of mozilla * start up instance B * exit instance A * exit instance B I often do that since I'm using an optimized build for dogfood, and debugging a debug build.

I see this problem most of the time. I do run multiple instances, all the time, since I'm running a release build as dogfood while I work with a debug build. Adding 4xp since it's a big downside to running mozilla vs. 4.x.

I'm updating the title slightly... I'm going to try to come up with a generic way of locking single-instance files so that we don't have this problem in the future... but this bug will track the fact that history is the most critical file for this. I'm also looking for a bug, which may exist somewhere, for deleting the history.dat file when it becomes corrupt.

I guess you found the other bug (bug 61140), since you fixed it :) (Btw, it tells you when it deletes your bad history.dat, right? I haven't checked.)

nav triage team: yes nice for next release

adding self to cc, I've been victim to this problem (multiple instances Moz-> corrupt history)

since this is a P3, moving to Mozilla1.0.

Marking nsbeta1+, no matter what we need to figure out how to handle running multiple instances. Maybe not this solution, but put on radar so that we think about it.

nav triage team: Not a 0.9.4 stopper, leaving at mozilla1.0

argh.. take two at reassigning history bugs to new owner

-> alecf

conrad, should I just mark this WONTFIX if you have profile-locking working? or can you point me at that bug and I'll mark this dependent?

Alec, it's bug 76431. That locks the entire profile which will avoid this. It would be nicer, though, for each consumer of profile data to lock its own data as needed. Global history, since it's needed continuously for the session, could just put inself in read-only mode on failing to acquire a lock on history.dat.

A decent roaming implementation will require that each consumer locks any data it uses in a more fine-grained fashion.

woah, 1.1 came up quick. Throwing these bugs over to 1.2.. little or no work has been done and there is no way that these bugs can be fixed in 1.1.

conrad has fixed this in the global case for now, so I'm futuring this. We'll bring it back from the future when we come up with a generic mechanism for doing this on individual files.

this history problem hits my .dat file several times a day - I moved up to ver. 1.4 and no help - I'm on winME and never run more than one instance of the browser - the corrupted history.dat is deleted at browser load time, but may continue to work for a while after the corruption happens (discovered this since I copy the file to history.bak while looking at the history window, but got a corrupted version anyway) - the history.dat can be edited by removing the last few entries and then starting the browser to see if it works, so far I've been able to repair it this way I read a lot of online forums (too many) and this is an important bug for me as I use history to identify unread msgs

For those still struggling with history.dat corruption, here are my results so far. Using Mozilla 1.3 on winME I lost my history 5 or 6 times a day when Mozilla crashed out. Using Mozilla 1.4 I lost my history 5 or 6 times a day when Mozilla crashed the whole system out. Using the workaround from bug#204374 about GDI resource exhaustion, (set browser.cache.memory.enable=false) I only had Mozilla 1.4 crash out the system 3 times in a whole week and only lost my history on two of those times. Now, using Mozilla 1.5a [2003081004] for 4 days now and pushing it hard, with browser.cache.memory.enable set back to true where it belongs, I've had no crashes yet and no loss of history.dat. I don't particularly like beta versions, but would recommend using the beta over using the workaround if you are still losing your history.

The last post here was six years ago. The issue reported was resolved at the latest in bug 374945 (implementation of Places). Resolving WFM.