Closed Bug 52181 Opened 24 years ago Closed 24 years ago

Unable to migrate a profile

Categories

(Core Graveyard :: Profile: Migration, defect, P1)

Product:
Core Graveyard
Component:
Profile: Migration
Platform:
PowerPC
Mac System 8.5
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: agracebush, Assigned: dbragg)

References

Details

(Keywords: platform-parity, regression, Whiteboard: [nsbeta3-][rtm++])

Attachments

(4 files)

Here's the patch which fixes this
16.23 KB, patch
Details | Diff | Splinter Review
ZIP file containing 4.75 dir and Netscape Registry
123.47 KB, application/octet-stream
Details
patch to close window in case of error
2.76 KB, patch
Details | Diff | Splinter Review
Alternative fix
522 bytes, patch
Details | Diff | Splinter Review 
Steps to reproduce:
1. download and install Mac build for 2000091111M18, having removed registry
file and documents folder
2. select 4.x profile for migration in profile manager
3. answer 'ok' to convert

actual results: confirm window closes and cursor settles on profile selected -
ie no migration takes place

expected results: migration of profile
this happens with mozilla profile manager also

it does not happen with Linux or Win
adding keywords
Keywords: nsbeta3, regression
addgin Conrad to the cc list, just in case.
You can't migrate ANY profile on Mac? This has got to be a P1 if that's true!

I really hate to stick Don with this one -- He's got other bugs to do and 
hasn't changed any code in this area. Any clue when this started breaking? I 
assume this is part of the regular install test and therefore it was the 9/11 
build that first showed the problem.

I wonder if this is related to dialog problems? that is, the progress dialog or 
something couldn't be instantiated and therefore bailed out before it got to 
the low-level profile code (in which case it wouldn't be Don after all).
Assignee: dbragg → racham
Keywords: pp
It doesn't look like this is related to underlying dialog bustage.

As far as I can tell it's never even getting in to the migration code.  In my 
test in the function nsProfile::MigrateProfile, the condition "already exists" 
is getting hit.  (appox line 1522 of nsProfile.cpp). Perhaps I had an aborted or 
failed migration attempt in the past.  I don't know how the folder got to 
documents:mozilla in the past but it was there. It then does a return 
NS_ERROR_FAILURE and never calls the migration code.  At the very least we 
should get a message (dialog or whatever) that tells the user this directory 
already exists rather than just returning to the Profile Manager.  Because when 
it returns to the PM and you try to run with that profile, you get the migrate 
message again.  Maybe this should be another bug.  Anyway, when I deleted the 
folder name in my documents:mozilla folder, the migration code was called.

Also, I get a javascript error when I tried this but I think this error is 
simply because the prefMigrator comPtr is not being created due to the erroring 
out in nsProfile.:

Javascript err:
 line 0:uncaught exception: [Exception..."Component returned failure 
code:0x80004005 (NS_ERROR_FAILURE)" [nsIProfile.migrateProfile]" nsresult: 
80004005 (NS_ERROR_FAILURE)" location: 
"JSFrame::chrome://communicator/content/profile/profileSelection.js :: onStart 
:: line78" data:no


Looks like linked to bug 51865 as in both cases profile exists is returning from 
the function.
unable to test migration / activation features
Severity: normal → critical
Conrad, do you see this on your mac ? There could possibly be a relation to
fetching the documents folder issue you are working on (52681).
Grace,

When you said activation, you were referring to the activation for migrated
profiles...right ? Ray has checked in fix yesterday for bugscape bug 2337 so
that activation window shows up. So, all new profiles should go through
activation now. Open a separate bug for activation, if needed, in bugscape for
the migrated profiles on mac.

I don't think it's related the the "Documents" folder not being present. I am 
running OS 9 and if I delete the "Documents" folder, a new one gets created and 
it works. I tried this about 2 days ago - as soon as this build finishes, I'll 
try again.

yes, I was referring to migrated profiles not being tested in activation- 
Franklin /USAnet etc.
It is working on other platforms
Activation is working on Mac
Conrad and I looked into the problem. It is a simple fix. A small 
nsIFile change regression. Reassigning to Conrad.
Assignee: racham → ccarlen
Fixed checked in. The problem was, when migrating a profile, if the dest folder 

already existed, it would just fail. What it should do (and used to do) is make 

the new folder unique. Not claiming fixed because, while fixes problem as 

described by dbragg, can't say it fixes problem as first reported. If the 

documents folder is deleted it worked before fix.
Status: NEW → ASSIGNED
After deleting registry and user folders, I was able to migrate the profile info
and migrate all profile folder via pref-migrator.

The only error case, I ran into was the one where profile dir existed and
registry was wiped out and we tried to migrate again. Conrad has already fixed that.


isn't this fixed?
this is not fixed in build 2000091804
documents folder is removed along with Mozilla Registry before attempting 
migration.

Note bug 52681- on my Mac, profiles are being stored in my installation 
directory by default, only application registry file is being stored in 
Documents folder 

changing severity to blocker- am not able to test migration or activated 
migrated profiles (webmail) etc
adding paw to cc list
Severity: critical → blocker
I'm looking at it. Is there an installation of Mac OS 8.5 on a server somewhere?
I don't know about that but you are welcome to use my machine 
OK, I can send you something as soon as I can build an optimized version. If the
Documents folder does not exist, I want to revert to using the Preferences
folder. See comments about creating "Documents" folder on bug 52681.

Grace, I sent the same thing I sent you to Bhuvan who has a Sys 8.5 machine. He 

said it fixed the problem. Will try to check in as soon as possible.
Priority: P3 → P1
Whiteboard: [nsbeta3+]
Checked in a fix for this. It should solve the problem of not creating the 
"Documents" folder on an 8.5 machine. There is another problem with migration 
right now, bug 53385, which I don't think is related. To test this, delete your 
"Documents" folder and try to migrate. If a "Documents" folder ends up being 
created (on an 8.5 Mac), this fix worked.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
fixed on build 2000092208
Status: RESOLVED → VERIFIED
*** Bug 53109 has been marked as a duplicate of this bug. ***
Just tried it with the latest build (2000-09-22-12).  Still no sign of any 
migration happening, with the same symptoms I reported before (see bug 53109).  I 
delete the Netscape application folder, the Documents folder, and the Mozilla 
Registry file before each time I try this.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
at least, I didn't notice this on Mac OS9.

I migrated 2 profiles successfully (migrate, bring up app , close app and
migrate again) using today's build.

Waldmar, can you migrate if you drag "Mozilla Profile Migration" onto the app? 
This works fine for me (and others). If there is a problem in your case, does it 
happen with a debug build? If so, can you take a look since I can't reproduce 
this?
As I understand the bug, Waldemar is doing an install as a dumb user, and not 
seeing *any* instructions or directions that would lead him to a migration tool.
IMO, if the answer is "you need to know about special knob X, or migration tool 
Y, and use it" then we have a problem. 
Doesn't migration come automagically, or get offered during a dumb install?
Thanks,
Jim (who has never installed on a Mac) Roskind
Waldermar,
Let me know when you are in and I will come by and try to see what is going on.

I also see this on Win32 today
2000-09-25-09M18
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Jim is right:  I was playing the role of a dumb user here.  As of the 2000-09-22-
12 build, there is no indication in the installation process that Netscape 6 is 
able to migrate old profiles or how to do it.  The installer 
(MacNetscape6Installer.sea.bin) doesn't offer or tell how to migrate anything, 
and neither does the application on first launch.

Dragging "Netscape Profile Migration" onto the Netscape 6 icon does bring up a 
profile selection menu that shows my old profile.  I can't open it due to a 
separate bug (a confirmation dialog telling me that it's a 4.7.5 profile comes 
back, and dumps me back right where I came from after I click OK), which I'm told 
is fixed in the latest build (I'd try it, but I am leaving for England in 10 
minutes).  However, the basic problem of dumb users not figuring out that they 
have to drag "Netscape Profile Migration" onto the Netscape 6 icon in order to 
get their old bookmarks, settings, etc. remains.

I have to retract my comment on win32, the converting dialog was opening behind 
the Profile Migration dialog, so I didn't see it. It actually did perform the 
migration on Win32.
OS: All → Mac System 8.5
Hardware: All → Macintosh
An average user would never need to drag icons anywhere in order to migrate,
unless he/she intentionally or unintentionally deletes the folder (Documents
folder) where the Application Registry is stored.

Installer on all platforms should automatically run the app with -installer
option (which actually does the profile registry info transfer). So, anytime app
is installed, it runs with this flag (bringing forward any 4.x profile added
since the last time the app was installed). So, An average user does not need to
do anything extra besides installing the product.

also Release Notes detail what occurs with ProfileManager/Migrator - depending 
on number of 4.x profiles.
I think it was a bad week to try migrating on Mac- because what should happen 
did not, making it confusing - good old default profile did get created and 
launch though.
I guess I need to clear some of the jorgan I used in my last update.

* -installer option : Today, we use this option (like mozilla -installer) to go
look in the 4.x registry and bring that information into the 6.0 registry. This
activity just transfers the profile entries from the registry to the new
registry. Migration of files (actually copying of files && modifying some to 6.0
format) from the old location to the new location happens when user clicks on OK
button of the dialog that asks user's confirmation for migration.

The only exception to this is, if the user has a single profile in 4.x,
Commercial product will do automigration (i.e., no confirmation dialogs).
Mozilla will ask for confirmation even in this case also.

*
" bringing forward any 4.x profile added
since the last time the app was installed "

All I was trying to say was, say you have 4.x profiles foo && bar. Then you
installed mozilla for the first time. At the end of the installation, you will
see profile manager window coming up listing these 2 profiles (ready profile
data migration). Let's say you migrated both these profiles. Then some time
later, you decided to have one more 4.x profile, lets say profile named "test".
One fine day, you will come across the new version of mozilla and decide to
install it. So, at the end of the installation, you will find profile manager
coming up listing profiles foo, bar (migrated) and test (unmigrated).

With Waldemar's position, I tried a recent build (2000092604) M18 after creating 
a second 4.x profile (per suggestion in bug 53385). On launch after installation 
Profile Manager came up showing both 4.x profiles, test and Waldemar.  I was 
able to migrate test profile but was not able to migrate Waldemar.  Symptoms 
were same as noted above. 

Grace, when doing this, after the second profile, was there a folder called
"Waldemar" in  :Documents:Mozilla:Users50:?

No, Waldemar truly did not get migrated

reread my last comment, meant to say with Waldemar's permission- I am using his 
machine to test
Is there a file "Mozilla Registry" in his Preferences folder?

yes,
before testing I removed it- along with documents etc - in fact found an old 
Mozilla Registry on another hard drive and removed it. 
Mozilla Registry was recreated as was Documents\Mozilla holding application 
registry (I think that is Mac name) and Users50
We should not hold PR3 for this.  It only affects a subset of Macs.  Nominating
for rtm and marking nsbeta3-
Keywords: rtm
Whiteboard: [nsbeta3+] → [nsbeta3-]
<me-too>
i also see this using today's 2000.09.28.12-n6 optimized bits, on Mac OS 9.0.
i've tried to migration with a clean installation, too.
</me-too>
I downloaded 2000.09.28.12-n6 and migrated two profiles successfuly with it on
Mac OS 9.

Update:  9/28 branch builds.  I cannot migrate my profile on Mac either.  
Interesting thing is that I can't migrate my persoanla profile now on Mac, Linux 
or Win98. It never finishes completing.  There might be some preference I use 
that's causing this as I have set up my 4.7 profile the same on all platforms 
and am using IMAP.  Other 4.7 profiles migrate on these system.  Seth is looking 
into this now.  I'll update when if we find what the problem is.
Note: Seth debugged the migration of 4.7 profile to 6.0 and found that my it
fails because of a localstore.rdf file that resides in my 4.7 profile.  When we
remove that file from my 4.7 profile and migrate the migration completes.  That
file was put there when using a bad Seamonkey build (around sept 5) that was
copying files into the 4.7 profile directory.  Hope this helps you with your
bug. See bug 54621

i'm now experiencing what esther saw above (using 2000.09.29.11-n6), except that
i cannot find either a localstore.rdf or panels.rdf within my 4.75 profile
directory. it just hangs during conversion.
There are 2 different problems being reported here: (1) migration appears to
never start (Waldemar) and (2) migration starts and fails to finish (esther,
Sairuh). With (1), Waldemar, can you send a copy of your ":System
Folder:Preferences:Netscape Registry" file? Having this file alone may allow me
to see why migration never happens. With (2) I will need to have both the
Netscape Registry and the profile dir to be migrated. Sairuh, is this possible?
Can you create a 4.7 profile which causes this problem but which does not
contain sensitive info?
Status: REOPENED → ASSIGNED
conrad, i have a sample 4.75 profile which won't get migrated --will attach the
files soon...
i lied... it took ~5min for the activation screen to appear (still using the
same branch bits, 2000.09.29.11, too. arrgh. mebbe it's just a matter of
waiting?
okay, i think i figgered out why i was able to reproduce this --namely, i was
trying to repro having more than one 4.7x profile (which didn't work). i'm now
able to get this problem to happen by doing the following:

1. clean out the netscape6 registry/mozilla user folder (as usual).
2. remove all 4.7x profiles *and* remove the Netscape Registry file from the
Preferences folder.
3. create a new (but only one) 4.7x profile.
4. attempt profile migration with netscape6.

result: the converting dialog stays up indefinitely.

now, i *will* attach those files you had asked for, conrad. :)
Sairuh, That profile dir you sent me sure does cause trouble. The "progress"
dialog stays up forever. The problem is deep in the pref migration code which I
am debugging now. At least now I have a case to debug!

the migration code happens on one thread, and the ui runs on another.

I wonder if on the mac, we are are starving one of the threads, and that is why
it takes 5 minutes.

adding thread event queue guru's (dougt and danm) to the cc list.

Looks like the thread which does the migration does not terminate if
ProfileMigrationController() returns early with error. The error, with the
profile you sent me, comes because a pref says the profile uses IMAP but none of
the IMAP folders actually exist in the profile dir being migrated. Notice how in
ProfileMigrationController(), if there is an error and it bails, the progress
window is never closed.

Wow, great catch Conrad.  If you want to fix this bug yourself, please feel
free. (After all, you did all the research).  But if you want to reassign it to
me (dbragg@netscape.com) you can do that too.  I leave it up to you.

great detective work, conrad!

it makes sense with that profile from sairuh, since when she created it in 4.x,
she never logged into mail.

luckily for us for nsbeta3, that is not a common usage pattern.  but it would be
great to fix this for rtm to gracefully handle errors, since more may be lurking.

(for example #54621)

thanks again, conrad.

Yes, this should be fixed since it looks like any error during migration will
cause this hang. Another lurking problem is if the disk fills up during
migration. Since work was done to put handling this in profile mgr, we need to
handle it in the migration code. I'll take a look and if it's as easy as closing
the window before returning, I'll fix it. If it's some hairy threading problem,
I may need help.

The above patch is pretty simple and worked when an error happened in pref
migration. The bit at the top of the file about the optimization pragma is
needed because, when doing an optimized mac build, compiling this file takes
HUGE amounts of memory (like 512 megs) and it takes forever. This could still
use some more investigation so I'll reassign. Maybe the error handling which
closes the window should be in the js?
Assignee: ccarlen → dbragg
Status: ASSIGNED → NEW
Looks good Conrad.  I think though that all we need to do is remove the "return"
right after the ProcessPrefsCallback call.  It drops through to the close window
function.  I'm investigating this fix right now.
Status: NEW → ASSIGNED
Attached patch Alternative fix — — Splinter Review 

    
    

    
  
Great, bugzilla lost my comments.

The S.E.V. Liberman profile was a problem profile since it had no prefs.js file.
 I really don't see how this would work in 4.x but that's not our concern.  We
just need to error out correctly and it looks like removing the "return" after
the failure of ProcessPrefsCallback will do that.  Attached the diff.  (That's
the previously logged message.


    
    

    
  
Need a r= and sr= noted in the bug before we can upgrade to [rtm+]

4.x will work just fine without a prefs.js, you simply get the default pref 
values. Only prefs that differ from the defaults are written back out to 
prefs.js so it's possible that if Sairuh had only defaults chosen maybe 4.x 
wouldn't write a prefs file at all. Seems unlikely, wouldn't we write at least 
the "do not edit this" header? And we'd write out at least the URL history 
entries. Hm, odd.
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm+ need review]

    
    

    
  
r=sspitzer on dbragg's patch.


    
    

    
  
Waldemar, I tried to migrate from the Netscape Registry file you sent. It
doesn't work. Stepping through the internalizing of data from this registry, the
"test" profile dir has a path of "Telemark:System Folder:Preferences:Netscape
Users:test" The "Waldemar Horwat" profile has a path of "Telemark:System
Folder:Preferences:Netscape ." The dot is in the data. I also get an assertion
about an unmappable character when this string is being converted from unicode
to ascii. Question is, does this profile work with Netscape 4.x? It seems
corrupt. What is the full path to this profile dir?


    
    

    
  
That 'dot' character is actually a florin (Option-f; MacASCII 0xC4) -- a 
legitimate filename character often used as an abbreviation for "folder" on the 
Mac.  I didn't pick the folder name; that name with the florin was created by an 
earlier version of Communicator (3.x or early 4.x I think).  As I upgraded 
Communicator through to my current 4.7.5, the profile folder name never changed.


    
    

    
  
we have a bug that covers the mac 3.x -> 4.x -> 6.0 problem.

I'll go find it.


    
    

    
  
found some.....This bug was originally an inability to migrate a 4.5+ profile 
and I am wondering if Waldemar's problem in migration is related to bug 11084 ( 
migration needs to be turned on for 4.0x) or bug 16896 (migration will fail if 
the users 4.x account was a migrated 3.x account)

    
    

    
  
bug #16896 discusses the problem with migrating a 4.x profile to 6.0 on mac if
the profile was really a 3.x profile.


    
    

    
  
sr=mscott


    
    

    
  
Got super review.  (Thanks mscott!) Changing to [rtm+]

Whiteboard: [nsbeta3-][rtm+ need review] → [nsbeta3-][rtm+]

    
    

    
  
PDT marking [rtm++]

Whiteboard: [nsbeta3-][rtm+] → [nsbeta3-][rtm++]

    
    

    
  
I fixed this bug per the attachment called "Alternative fix".  It actually
doesn't fix the migration of Waldemar's profile since I think that's a problem
with the profile itself.  What it does fix is the removal of the progress
windows if an error occurs during the migration.  (Examples include missing IMAP
dirs or a missing prefs.js in the 4.x profile)

This is the fix that PDT approved.

Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED

    
    

    
  
I was able to verify this on build 2000100910MN6 using the profile that sairuh 
attached.  My profiles also migrated- adding vtrunk
Keywords: vtrunk

    
    

    
  
Verified on the 10/31 trunk build.
Status: RESOLVED → VERIFIED
Keywords: vtrunk
Product: Core → Core Graveyard

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: