Open
Bug 621974
Opened 14 years ago
Updated 14 years ago
Profile migration per -migration doesn't migrate history
Categories
(SeaMonkey :: Startup & Profiles, defect)
Tracking
(Not tracked)
NEW
People
(Reporter: mnyromyr, Unassigned)
Details
Profile migration per -migration will import into the currently used profile (if any, see bug 621957). This doesn't migrate any history data, though.
![]() |
||
Comment 1•14 years ago
|
||
It should copy the history.dat and that should be converted by places on encountering it - of course, that only happens if there's no places data there yet. If it works the way I pointed it out, I suggest WONTFIX.
Reporter | ||
Comment 2•14 years ago
|
||
I assume by "no places data there" you mean "no places.sqlite exist", because even an empty places.sqlite will deny migration. The problem is that if you already have profiles, you will always have one of those taken on startup, and this profile will usually have been used before and thus not migrate the history data anymore. I fail to see how not migrating history just because there already is an sqlite file should be intended behaviour - it's clearly a bug. (Just a case of "not yet implemented", imo.) If I can start migration manually and can choose the profile where to migrate to, the migration should happen.
![]() |
||
Comment 3•14 years ago
|
||
Feel free to figure out an algorithm that doesn't harm startup perf at all (SeaMonkey is bad enough as it is) and figures out if the given history has already been imported or not and possibly even get that into the places code, which is where all the import is done right now. I won't even waste one thought about that.
You need to log in
before you can comment on or make changes to this bug.
Description
•