Both Mozilla and N6 are now "converting" existing NS4.7x files and preferences. That's good. The bad news is that (regardless of what drive you select for the program install) they create a new "converted" user file on Drive C: under Windows/Applications. If one has a big set of news and mail, this can be quite big. We carefully segregrate our OS stuff to Drive C: and our Apps/Programs to Drive D: - getting a whole big and unwanted collection of new N6/Mozilla files on Drive C: is a nuisance and takes up a lot of space. So here's my hope - you make NG/Mozilla put ALL its files (even the new, converted user files) on the selected program drive - or, at least, tell me how to get them there (and recognized) once it puts them on C: Thanks. George Beker Creative Director Center for Non-Profit Resources http://www.cnpr.org

not installer...

Changing summary to reflect specific bug.

Marking as NEW its a really good idea.

yes, this is not installer. resetting bug to owner of selected component.

I think this is a dup of bug 55309 (where we ask for storing the migrated files in the location of user's choice).

It's actually a closer dup of bug 24954. I plan to make it possible to specify the destination folder for migrated profiles. Don, if this doesn't get resolved as a dup, you can assign it to me.

Reassigning to ccarlen per his comments.

Since I reported this bug back in 2002, each subsequent version of Mozilla still has it. Is there any plan to fix this to give folks the option of WHERE to put the migrated files? If not, you've list me as a user - and probably some others. Gad! This is just like Microsoft . . . Sincerely, George Beker Creative Director Center for Non-Profit Resources http://www.cnpr.org

Yes, there is a plan to fix it. Sorry if it's not soon enough.

*** Bug 77709 has been marked as a duplicate of this bug. ***

*** Bug 24954 has been marked as a duplicate of this bug. ***

-> 0.9.2

-> mozilla1.0 Considering that this would require a change to the UI and documentation, it's not going to happen too soon.

*** Bug 85022 has been marked as a duplicate of this bug. ***

*** Bug 89887 has been marked as a duplicate of this bug. ***

Would it be possible to at least provide a commandline option to specify the desination directory of the migrated data?

This is a serious problem and shouldn't be a P3. My C: drive only has about 300 MB of data. My migrated email profile is very close to that size. The migrated profiles need to be on the drive where the program was installed, not on C:, or alternatively an advanced install option should be available to select it. FYI it seems the bug is specific to Windows builds. The OS/2 Mozilla build properly writes migrated profiles to the drive where the browser bits are extracted, but it has no installer.

I meant I only have 300 MB free on C: . So when I do a migration it nearly fills the drive. I'm still using Communicator as primary mail client due to some missing features/bugs in NS6 mail client. At some point soon, my mail folders will be too large for me to be able to pick up new Mozilla/NS6 builds due to running out of space during migration.

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)

*** Bug 104534 has been marked as a duplicate of this bug. ***

*** Bug 154389 has been marked as a duplicate of this bug. ***

*** Bug 152394 has been marked as a duplicate of this bug. ***

Thanks for adding my bug 152394 here, it is indeed another duplicate of a longer existing problem reported by several other people. Everybody who holds OS on a separate small drive, 1Gig in my case, will not be able to use automated profile creation until the location of the new profile will be specified. I agree with the observation that this should not be a low priority bug, the more that is appears to be easy to resolve.

-> future

Marking all since it applies to all WIndows.

This bug is filed in a bugzilla component related to pre-Firefox code which no longer exists. I believe it is no longer relevant and I am therefore closing it INCOMPLETE. If you believe that this bug is still valid and needs to be fixed, please reopen it and move it to the Toolkit:Startup and Profile System product/component.