If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Migration wizard doesn't work when upgrading from SM 1.1.18 to 2.03.

RESOLVED WORKSFORME

Status

SeaMonkey
Startup & Profiles
--
major
RESOLVED WORKSFORME
8 years ago
6 years ago

People

(Reporter: Craig, Unassigned)

Tracking

SeaMonkey 2.0 Branch
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: DUPEME [SmBugEvent])

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100205 SeaMonkey/2.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100205 SeaMonkey/2.0.3

Absolutely nothing is transferred to the new SM 2.03 profile from the still-existing 1.1.18 profile, even though it tells you that it has been. Both versions of SM were installed to a non-default location, on a different partition (E:\Mozilla\SMonkey).

Of possible interest: After installation the command line

"E:\Mozilla\SMonkey\seamonkey.exe" -P "new profile" -migration

also does NOT work.


Reproducible: Always

Steps to Reproduce:
1. Uninstall SM 1.1.18.
2. Install SM 2.03, tell it to migrate existing profile.
3. Run SM 2.03.
Actual Results:  
Zero. Defaults throughout.

Expected Results:  
Expected accounts, emails, passwords, bookmarks, history (and so forth) to show up in the new install.

Comment 1

8 years ago
Craig, have you tried installing SM 2 whilst you still have SM 1.1.18 still installed??
(Reporter)

Comment 2

8 years ago
(In reply to comment #1)
> Craig, have you tried installing SM 2 whilst you still have SM 1.1.18 still
> installed??

I haven't, because there seemed to be a consensus when I downloaded 2.03 that it was best not to. I may give it a try, thanks for the idea.
Component: General → Startup & Profiles
QA Contact: general → profile-manager
Whiteboard: DUPEME
Version: unspecified → SeaMonkey 2.0 Branch

Comment 3

8 years ago
Craig, the process, as I understand it is,
1.     You're using SM 1.1.18, no great problems, but hear that SM 2.x.x is released.

2.     You download SM 2.x.x and give it a test (with a profile that is a clone of your SM 1.1.18 profile) whilst you continue using SM 1.1.18.

3.     When you are happy that SM 2.x.x is better than SM 1.1.18, you delete SM 2.x.x, you delete the clone profile, and you re-install SM 2.x.x so that it makes an up-to-date copy of your SM 1.1.18 profile

4.     THEN you delete SM 1.1.18 and its profile.

As I understand it, your profile location is known to SM 1.1.18, not specifically to your operating system. So if you delete SM 1.1.18 before you install SM 2.x.x, SM 2.x.x has no way of knowing where your (now orphaned) SM 1.1.18 profile is/was.

The confusion (consensus that you speak of) may have arrived from the fact that you should not install SM 2.x.x into the same location as SM 1.1.18, Otherwise, I don't know what the consensus was about.
(Reporter)

Comment 4

8 years ago
(In reply to comment #3)
> Craig, the process, as I understand it is,
> 1.     You're using SM 1.1.18, no great problems, but hear that SM 2.x.x is
> released.
> 
> 2.     You download SM 2.x.x and give it a test (with a profile that is a clone
> of your SM 1.1.18 profile) whilst you continue using SM 1.1.18.
> 
> 3.     When you are happy that SM 2.x.x is better than SM 1.1.18, you delete SM
> 2.x.x, you delete the clone profile, and you re-install SM 2.x.x so that it
> makes an up-to-date copy of your SM 1.1.18 profile
> 
> 4.     THEN you delete SM 1.1.18 and its profile.
> 
> As I understand it, your profile location is known to SM 1.1.18, not
> specifically to your operating system. So if you delete SM 1.1.18 before you
> install SM 2.x.x, SM 2.x.x has no way of knowing where your (now orphaned) SM
> 1.1.18 profile is/was.
> 
> The confusion (consensus that you speak of) may have arrived from the fact that
> you should not install SM 2.x.x into the same location as SM 1.1.18, Otherwise,
> I don't know what the consensus was about.

The consensus I referred to seemed to revolve around the likelihood of glitches when both versions were present on the system simultaneously. I did note that both shouldn't be in the same place at the same time.

My 1.1.18 profile was/is in the default (I think) location, however eccentric my choice of where to put the program files.

I seem to have (probably inadvertently) done something right. My 2.03 installation has yet to show any signs of instability, or file corruption, with all features present and accounted for and still working smoothly.

I'm thinking Seamonkey developers could do users a big and ongoing favor (and avoid hassles for themselves) if they would simply post a page featuring specific lists of files, and a checklist, for a best practice manual profiles transfer when the migration wizard bombs, whenever a new version of SM comes out.

I'm copying your checklist, and thank you for it.

Comment 5

6 years ago
Not too clear, but Resolved by the OP per Comment 4.

Updated

6 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
Whiteboard: DUPEME → DUPEME [SmBugEvent]
You need to log in before you can comment on or make changes to this bug.