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.
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
Last Resolved: 16 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.
You need to log in before you can comment on or make changes to this bug.