Closed Bug 184888 Opened 22 years ago Closed 22 years ago

Mozilla 1.2 does not migrate a 1.1 installation

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
OS/2
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: ok34, Assigned: asa)

Details

(Keywords: dataloss) 

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.2.1) Gecko/20021201
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.2.1) Gecko/20021201

I just wanted to switch to Mozilla 1.21 (OS/2) (20021201). Since this build now
comes not as a Zip file, but as a binary installer, I wanted to upgrade my
existing installation by installing into the directory of my 1.1 installation.

First, everything looked fine. The installer realized the presence of the 1.1
and wrote lots of "replacing xxx" messages. And I could launch 1.21 without error.

Error 1: 1.21 comes up with a totally empty sidebar, and nothing to put into it... 

My preferences have been migrated. The theme is correctly selected (Modern), my
start page is correctly set (but Mozilla opens mozilla.org despite the setting),
the bookmarks are there, and mail and news settings are correct.

Error 2: Mail doesn't work...

Although all settings look fine, it does not fetch mail from any server that is
configured there, and it does not send mail. I cannot even type the body text of
the message. Nothing happens when I click into the body text entry field and
type something...

Error 3: News doesn't work...

All news servers and their settings have been migrated, but I cannot open them
by clicking on their listings in the window...


Reproducible: Always

Steps to Reproduce:
1. Install Mozilla 1.21 in the same directory where a fully configured 1.1 resides.
2. Launch
3. Look at sidebar, launch mail window and try to send/receive mail. Try news.

Actual Results:  
No sidebar, no mail, no news. See above.

Expected Results:  
Sidebar, mail and news should have been migrated or a message should inform user
that migration is impossible (and provide an alternative way to move all those
bookmarks, mails, preferences etc. etc.).
Reporter:
Have you installed 1.2.1 over an zip based installation ?
(if yes invalid since unsupported)

If not :
delete the file "xul.mfl" in your profile and try it again.
Severity: major → critical
Keywords: dataloss
Yes, because 1.1 (Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.1) Gecko/20020827)
was only available as Zip based. Now I chose the installer for comfort reasons.
And there is no warning against such installation.

Btw, as I wrote, if such migration is unsupported, then there should definitely
be an error message that warns the user. And, of course, an alternative
migration path becomes necessary to move all the information from 1.1 to 1.21...
I just tried migration with xul.mfl deleted before-hand: Still no sidebar, no
mail, no news.
The installer can't know if the old installation iks from a .zip.

Please uninstall mazilla, delete the directory (except plugins) and reinstall
mozilla.

Well, it makes a difference whether an installation was done by an installer or
whether it came out of a Zip file, then there is a difference in the files on
the hard disk, and then the installer can now the difference...

The problem is not that I am unable to get 1.21 up and running, I want to
migrate all my data and preferences, and I believe this is a legitimate wish...

I do not care whether migration is comfortably done within the installer or
whether the installer can only make a new installation in a new directory.

But if the latter is the case, then a) the installer _must_ warn the user and b)
we need an "import profile" feature so I can extract all these data from the old
directory into the new one. Such feature should be available from the profile
manager that pops up when the new installation is started for the first time.

Currently the profile manager only migrates my very old data from the Netscape 4
installation that is still on my hard disk, but not profiles from Mozilla
installations.
Your Data is NOT in this directory.
The profile Data is in the OS User directory and it will not deleted if you
uninstall mozilal and/or delete the c:\programs\mozilla.org folder.

Mozilla can't import your profile again because it should work with your old
Profile. (my current Profile is from Mozilla M18 (before M0.9.0).

There are only known problems with old Themes in your profile.
BTW: A broken profile can be repaired to 95%-100%

Installing over an older zip based build COULD cause this problems.

My paths are these:

I installed 1.1 (and previously 1.0) in D:\BIN\MOZILLA. Therefore the binaries
reside in D:\BIN\MOZILLA\BIN\, and my profile is in
D:\BIN\MOZILLA\BIN\MOZILLA\PROFILES\KLUGE\RDFEYYY4.SLT\. Mail resides in
D:\BIN\MOZILLA\BIN\MOZILLA\PROFILES\KLUGE\RDFEYYY4.SLT\MAIL\POP.1UND1.COM\ Under
OS/2, there is no such thing as an OS user directory. Also, Mozilla does not
seem to make use of the HOME environment variable that OS/2 borrows from Unix
(to emulate a home directory).

If I remove the Mozilla directory tree, my profile and all data are gone.

But even if I do not remove it and let the installer install into a fresh
directory, it does not make use of existing profile data. Instead, the profile
manager after the first launch of Mozilla offers my to reconvert my old Netscape
4 profile. The only alternative to that is a completely new (empty) profile. 

Existing Mozilla profiles are neither re-used nor imported. They are completely
ignored, rendering all e-mails and other data in them useless under Mozilla 1.21.
sorry, Mozilla use the OS Directory for all OS (MAc, Linux, Win32) but it seems
not OS/2 :-(
I can't help now because i don't know where your registry.dat (or apreg.dat or
whatever) is stored.
OS: other → OS/2
D:\BIN\MOZILLA\BIN\MOZILLA

Maybe I should - in addition to this bug - make a meta bug for improvement "make
use of the HOME variable" (using TMP for cache would be nice, too). Mozilla does
use some environment variables - TZ for example.

But still a solution is needed for migrating profile data.

A migration feature inside the installer or the profile manager does make sense
even an OS user directory is used - think of cloning your installation on your
laptop...

If you had used the MOZILLA_HOME directory as we have repeatedly told people to
do, this wouldn't be a problem.

As it is, this bug is INVALID because you can't install an installer build over
a ZIP.

This is a development product and it is still in development.

We're not going to support going from any version to any version.


FYI We have already a  Mozilla Profile Import bug :-)

The question is now if your old profile works if you have a clean install.


Let me be more detailed.

The installer has knowledge of what files have come and gone between releases
and knows how to remove unnecessary files and stuff like that.

When you installed over 1.1, bad things happened. In particular, duplicate XPT
files in components directory.

When we switched to the installer build, we now have less xpt files. To fix
this, delete all xpt files except:
inspector.xpt, mail.xpt, browser.xpt, psm.xpt, irc.xpt, venkman.xpt
Then delete compreg.dat or component.reg and restart.

I did this and it worked fine for me.

I am not going to add a list of the old XPT files to the installer so that it
deletes them. That would be silly.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
I have no idea why you use so harsh words. I do not think I gave reason to be
harsh. I am trying to help improve the product, as I have done in the past.

>   If you had used the MOZILLA_HOME directory as we have repeatedly told
>   people to do, this wouldn't be a problem.

I cannot remember seeing this in a documentation for Mozilla on the OS/2
plattform. I know this from the Linux plattform, but cannot remember this from
OS/2. I'll have a look at 1.1.

>   As it is, this bug is INVALID because you can't install an installer
>   build over a ZIP.

Yes, maybe this is unsupported, and I understand the reason why. But the
installer _must_ tell users about that. In essence this means that it is
impossible at all to use the installer version of 1.21, because there was no
installer for 1.1, at least to my knowledge. To not support migration is okay,
but please tell people...

As I wrote, not having a migration procedure in the installer is fine, as long
as the profile manager is capable of not only reading Netscape 4, but also
Mozilla profiles... ;-)

>   This is a development product and it is still in development.

This is not a beta version. In a beta restrictions like this are totally
acceptable, but if you label it like a stable version, and more so if the label
is 1.2_1_, you should at least make restrictions clear.

>   The installer has knowledge of what files have come and gone between
>   releases and knows how to remove unnecessary files and stuff like that.
[...]
>   I am not going to add a list of the old XPT files to the installer so
>   that it deletes them. That would be silly.

That is a direct contradiction... If the installer has knowledge what files have
gone in 1.2 and "knows how to remove unnecessary files", then where is the
problem? Then it does already have a list of old XPT files for deletion, doesn't it?

But thanks for your help, I will try to delete them manually and report about
the success.



Okay, here is my report on the _success_:

>  delete all xpt files except:
>  inspector.xpt, mail.xpt, browser.xpt, psm.xpt, irc.xpt, venkman.xpt
>  Then delete compreg.dat or component.reg and restart.
>  I did this and it worked fine for me.

I deleted all xpts, but irc.xpt and venkman.xpt _do not exist_. I deleted
compreg.dat _and_ component.reg and restarted, and everything looks fine now,
thank you once again.

If it's that easy to fix the whole problem - even if such installation/migration
is unsupported, a mere check for existence of e.g. components/absync.xpt would
be all that installer would have to do to realize that there is a Zip
installation on the disk - and then either delete those files or display a
warning that such migration is unsupported...

Btw., the fact that above steps worked "for you" tells me that you had the same
problem I had - so at least two people had the need for such a migration ;-)
Again, thanks...



I only tried it because you had the problem :)

I'll look at the possibility of putting this in the installer.
Once again, thanks.

But what I still don't understand: What is the difference between Zip and
installer installations, if there has been an installer version of 1.1 for OS/2.

Did the Zip include more files than the installer would have copied? And if so,
why does that produce errors like the ones I've seen (empty sidebar etc.)?

If Zip installations produce such risks of migration, then why not make a cut
and discontinue them altogether?
The ZIP did contain additional files because once we got the packaging scripts
working, many small XPT files were contained into bigger files.

The reason you saw your problems is because XPT files are processed
alphabetically. So most of the interfaces registered were 1.1 interfaces since
the 1.2.1 interfaces were in browser.xpt.

The zips are there mainly for some people that really want the zips and to allow
quick instals for testing purposes.

Many people want to keep the zips so they don't have to go through an install
each time.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.