Closed Bug 635536 Opened 13 years ago Closed 13 years ago

History is deleted when switching back to Firefox 3.5

Categories

(Toolkit :: Places, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: jrmuizel, Unassigned)

Details

It seems like I loose my history when ever I switch back to Firefox 3.6
(In reply to comment #0)
> It seems like I loose my history when ever I switch back to Firefox 3.6

That should be Firefox 3.5 instead 3.6
Summary: History is deleted when switching back to Firefox 3.6 → History is deleted when switching back to Firefox 3.5
blocking2.0: --- → ?
This was an intentional decision.  You can recover it by renaming places.sqlite-corrupt back to places.sqlite, but the version of SQLite shipping in 3.5 does not support the database format we use in 4.0.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
It seems like we should do something better than silently renaming it.

Shouldn't we give a message like "This profile you're using is from a newer version of Firefox" and then have it use a new profile, so that when you switch back to the more recent version you still have all of your history?
(In reply to comment #3)
> Shouldn't we give a message like "This profile you're using is from a newer
> version of Firefox" and then have it use a new profile, so that when you switch
> back to the more recent version you still have all of your history?
It's kinda hard to add strings to older branches, for one.  Secondly, SQLite just thinks the database file is corrupt, so we really can't tell that apart from an actually corrupted database file.
(In reply to comment #4)
> (In reply to comment #3)
> > Shouldn't we give a message like "This profile you're using is from a newer
> > version of Firefox" and then have it use a new profile, so that when you switch
> > back to the more recent version you still have all of your history?
> It's kinda hard to add strings to older branches, for one.

Fine, but how about if we change the format in the future? Shouldn't we have the transition code ready?

> Secondly, SQLite
> just thinks the database file is corrupt, so we really can't tell that apart
> from an actually corrupted database file.

The disk formats are versioned. Is there no api exposing them? That seems like a poor decision.
blocking2.0: ? → ---
(In reply to comment #5)
> Fine, but how about if we change the format in the future? Shouldn't we have
> the transition code ready?
Possibly, but shaver keeps telling me we need to stop worrying about downgraders.  Until I hear a definitive answer on this, I think we are unlikely to invest much effort here.

> The disk formats are versioned. Is there no api exposing them? That seems like
> a poor decision.
That's something you could take up with the SQLite team.
You need to log in before you can comment on or make changes to this bug.