Delete history.dat when it gets corrupted

VERIFIED FIXED in mozilla0.8

Status

()

Core
Document Navigation
P1
normal
VERIFIED FIXED
17 years ago
10 years ago

People

(Reporter: Moses Lei, Assigned: Alec Flett)

Tracking

Trunk
mozilla0.8
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
I've been browsing for a while, and then I pop the history window up (Ctl-H). I
don't see anything! The history window used to work, iirc.

Or am I missing something more obvious? (I've been known to do things like that)

Steps to reproduce:
Browse some pages.
Open history window.

Expected result:
Should see history listed.

Actual result:
Don't see a single entry.

Linux build 2200112406, attaching screenshot to show what I mean.
(Reporter)

Comment 1

17 years ago
Created attachment 19679 [details]
screenshot

Comment 2

17 years ago
Yeah, I'm seeing this too. Confirming and suggesting upping the priority- this
is a nasty regression that should be dealt with.
Status: UNCONFIRMED → NEW
Ever confirmed: true
reassigning to module owner
Assignee: radha → alecf
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Priority: P3 → P1
Target Milestone: --- → mozilla0.8
(Assignee)

Comment 4

17 years ago
it seems to be failing to load the datasource. looking into it.
(Assignee)

Comment 5

17 years ago
ok, I'll bet the problem is that your database is corrupt... can you remove your
history.dat and try again? The file gets corrupted if you run two instances of
the browser at the same time (with the same profile)

We are supposed to be blowing the history.dat file away if it is corrupt, but I
don't see any code to do that. adding radha back to the CC to see if she knows
of the bug # for deleting the history file when it becomes corrupt.
(Assignee)

Comment 6

17 years ago
ok, I'm going to morph this bug slightly, since I can't quite find a dupe
Summary: [regression] History window blank → Delete history.dat when it gets corrupted
(Assignee)

Comment 7

17 years ago
see also bug 31575 for locking history.dat so this doesn't happen again.
(Reporter)

Comment 8

17 years ago
Is there no way of sharing the history.dat between the two sessions, or is that
too ugly?

How does NS 4.x deal with this?
(Assignee)

Comment 9

17 years ago
there is no way, sorry
On Windows/Mac, 4.x only allows once instance to run.. if you manage to get two
instances to run it corrupts the history
on unix, it shows you an alert telling you there is another instance running,
then it locks history.dat
if you somehow get two instances running, it will corrupt the history

also, the 4.x data format was different so the results of the corruption would
have been different (i.e. perhaps it was slightly more "readable" by 4.x)
(Assignee)

Comment 10

17 years ago
*** Bug 61994 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 11

17 years ago
fix is in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31.

if you think this particular bug is not fixed, please make sure of the following
before reopening:

a. retest with a *recent* trunk build.
b. query bugzilla to see if there's an existing, open bug (new, reopened,
assigned) that covers your issue.
c. if this does need to be reopened, make sure there are specific steps to
reproduce (unless already provided and up-to-date).

thanks!

[set your search string in mail to "AmbassadorKoshNaranek" to filter out these
messages.]
Status: RESOLVED → VERIFIED

Updated

10 years ago
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.