Need ability to specify with -installer the Users directory 2000-01-24 M13 win32 build 1) I run mozilla.exe -ProfileWizard and specify my users directory to be something like: d:\users50. Profile gets created. 2) I want all my future profiles to go into that directory. There is one profile that I want to migrate from 4.x so I run mozilla.exe -installer. 3) The profile / files get copied to some users50 directory where my executable is installed and not to the d:\users50 directory. I would like to be able to specify where the users directory gets created when using -installer or have it use the users50 directory that's already present.

per Seth.

I don't think this is critical for beta. Marking this M15. I will try to certainly pull this into M14, if the current list can be done with a leeway.

Posting barney's comments : In light of the bug 6464 fix, I'd really appreciate somebody giving bug 24954 another look. Maybe all the sys admin types out there love this new location for the Users50 directory (bug 6464 fix), but it's not quite doing me a favor on my stand-alone Win98 PC. I don't want my 3 profiles in the C:\Windows dir (mainly due to space limitations) and I've been unsuccessful at getting migrated 4.x profiles to be recognized in any other location. I've cursed M$ a zillion times for throwing stuff on the c: drive against my wishes, and don't want mozilla to start doing it, too. Editing c:\windows\application data\mozilla\registry.dat to point to another drive/dir name, such as e:\program files\mozilla\users50\<profile> (where I really want profiles) does not have any effect, other than causing mozilla to go blind and fail to locate anything. I can relocate mail and news folders in prefs after a 4.x profile is converted, but cache, bookmarks, and other files in the profile apparently gotta be in the %windir%\...\mozilla\users50\<profile> folder or mozilla ignores them. To me, this is unacceptable and considering my drive space, makes mozilla almost unuseable with 3 profiles. And I even tried changing the windows registry to point to e:\application data without success - mozilla still insists on using c:\windows\... Having %windir% as a _default_ location is just hunky-dory, but there should have been some user control provided to override it for _migrated_ profiles, not just new ones. IMHO, and I'm probably in the minority, it was better off before the bug 6464 fix. At least then profiles were on my d: drive with the application instead of c:, which is really crunched on space. barney

Conrad, This will be a useful one to fix. Sooner or later, users are going to fill their C drives (windows only) and start getting disk space errors all over the place. It probably is bad sign and user may have to deal with disk cleanup. But I think we should avoid ourselves from driving people to that state...

Agreed. Since we allow the user to specify a directory for profile creation, we should allow the same for profile migration. Have to think about this with auto migration because that's not supposed to involve any UI.

Setting milestone to mozilla0.9

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

-> 0.9.1

Marking as duplicate of bug 60734. *** This bug has been marked as a duplicate of 60734 ***

verify duplicate

This bug is not a duplicate of bug 60734. Specifying a location and specifying a drive are not synonymous concepts. The ability to specify a drive only is little help in preventing profiles from landing in X:\Documents and Settings\username\Application Data\Mozilla\Profiles\username\gobbledegook.slt instead of a comprehensible and backupable X:\Mozilla\Profiles\username.

Can we set the target milestone to mozilla0.9.7 or above ?

-> 0.9.9

thx :)

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

This feature will benefit client deployment and distribution.

-> 1.0

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

I'd also like the ability to specify a remote path so that users could store their profiles on a network server and have access to them from anywhere on the LAN. This should be specified through the use of environment variables or usernames -- on a Windows workstation on a Netware network or SaMBA/Win network in the system login script a virtual drive letter like U: would be created pointing at the user's , and each user's profiles are in U:\Netscape\Users\Default. On a *BSD/Linux network I'm sure the same procedure could be worked out. This would allow a use to log in to the network from any workstation and have personal settings. THIS IS NOT A ROAMING PROFILE where the profile is copied to the server when Mozilla shuts down and then copied to the local workstation when Mozilla starts. The profile info stays on the server all the time.

-> 1.0.1

ADT need info. Pls let us know how this impacts OEMs or other customers.

I couldn't find any comment in this bug report saying that '-install' (or other switch) can be used to indicate where the migrated profile or a new profile will be. Could anyone shed some light on how to do so?

Here is a related comment received in the CCK feedback: ... Is there a plan to provide any sort or programatic or automation interface to user profile creation services within Netscape 6.x. In the Netscape 4.7x version I use a really awful vbscript utility to do some brute force automation of the profile creation process. This allows default profiles to be created for each individual as they logon to a Windows 2000 workstation. This default profile conforms to a standard template across the [name deleted] enterprise (~150,000 Windows desktops). My preference in this area is that even though I can preconfigure the browser using CCK, I would like to create the user profiles in a standard location using a standard name. Within Boeing I use the users NT Logon ID as the profile name. Is there a more elegant way to automate the Profile wizard in Netscape 6.x? Can you refer me to any documentation that might illustrate how a technique could be developed? If I can generate a profile in a defined location, I could then manually manipulate the resulting profile and register the specific changes. ...

Currently we use NS4.7x with the profiles stored on a networked drive for each user (N:\Netscape\Users\<username>) and we would like to continue this method when we deploy mozilla/NS6.x so this is a show stopper as far as we are concerned. There are probably two levels to the fix, one being a command line switch that specifies the location for profiles when migrating and two being some sort of GUI that prompts for location with a choice of selecting the default location, amending the one picked up from the netscape profile or one of your own choice. Being able to type the path as well as browse would be very useful as we hide certain drives at our site including the one used to store the current Netscape profile to stop users accidentally deleting it.

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.

Bhuvan told me that the cmdline switch, -createProfile, with "foo foodir" as argument will create profile, "foo", in "foodir" w/ salted subdirectory. One step closer to the finish line :-)

-> future

This patch introduces two new prefs to all.js pref.migration_useprofilesroot when set to: true - keeps existing behaviour false - behaviour depends on setting of next new pref pref.migration_directory when set to: null/empty - sets profiles root based on NS4.x location non-empty - sets profiles root to be the content of the pref This is only the first pass at resolving this - any constructive feedback?

BTW I wasn't sure if it was best for this patch to be on this bug or bug 55309 or bug 60734 but it ended up here - I blame the hour (almost 2am).

pref.migration_useprofilesroot pref.migration_directory Could not both these prefs be replaced with just pref.migration_directory. If set and/or not the empty string, then it is used, otherwise the default behaviour occurs? Somewhat off-topic, would you be able to look into whether mail is copied or moved from the original netscape profile? This is bug 92295 and is a bit related to this one.

I think it would be useful to have the three options as I'm sure some people would want the option to have it based on the current location of the NS4.X profile.

Profile migration! Ugh! Alright, bear with me, I'm new to this particular enhancement, despite its immense age. The code seems fine to me, as far as it goes. Though I'm with Ian; I don't see the utility of supporting the ability to co-exist inside the old Nav4 profile. It does make the code a little confusing. I wonder if, from an API standpoint, it would make more sense to do it this way: pref profile.migration_directorytype (or perhaps some better name), with three values: new directory in standard Mozilla profiles location (the default); co-exist alongside original Nav4 directory; use directory named in the profile.migration_directory pref. That seems more clear to me. Whaddaya say? mechanical nit: localFile->QueryInterface(NS_GET_IID(nsIFile), getter_AddRefs(newProfDir)) is rather old-style. don't you mean just newProfDir = do_QueryInterface(localFile) there's also newProfDir = do_QueryInterface(localFile, &rv) for those anxious to pay tribute to the error return code.

Taking

Accepting

Now uses profile.migration_behaviour to determine how to set the profiles root for migrating profiles. 0 - use NS_APP_USER_PROFILES_ROOT_DIR 1 - create one based on the NS4.x profile root 2 - use, if not empty, contents of profile.migration_directory, otherwise same as for 0 Addresses mechanical nit too.

Comment on attachment 135202 [details] [diff] [review] Patch v0.2 - makes use of int instead of bool pref Seems fine to me. r=danm. I do apologize for saying this but please use the American spelling for behaviour. I usually use the British spelling myself, and I love a good spelling war. But the rest of the file tends to take the American side. That includes two uses of the same word, all u-less. Consistency is all I'm asking. Oh obviously in my last comment I got my Ians and my Maxes confused. Sorry.

Behaviour now spelt as Behavior

Comment on attachment 135278 [details] [diff] [review] Patch v0.2a - same as v0.2 except with American spellings Carrying forward r= and requesting sr

Comment on attachment 135278 [details] [diff] [review] Patch v0.2a - same as v0.2 except with American spellings biesi suggested I get a review from ccarlen too

aiming

Is 1.6b branching still scheduled for tonight?

no. the freezing will happen tonight; a branch for 1.6b will not happen, as branches are not created for alpha and beta...

I like it but... It won't be possible for Mac users to enjoy this because file prefs on Mac are written as base64 encoded aliases so, unless somebody was clever enough to set some other file pref to the dir they wanted and copy that in their prefs file to the value of profile.migration_directory, they'd be out. Instead of using prefBranch->GetComplexValue() to get a nsILocalFile, you could just fetch the path as a string and use nsILocalFile::InitWithNativePath(). Though, being a native path, it would create one more hurdle for platform-independent prefs. But, native paths are no less platform-independent than the storage format of an nsIFile as a ComplexValue. Also, this pref is in all.js and therefore part the app install (inherently 1 platform), not a profile (maybe someday xp). Fetch the path as a string instead of a ComplexValue, and I'm fine with it.

Comment on attachment 135278 [details] [diff] [review] Patch v0.2a - same as v0.2 except with American spellings Cancelling old request

Patch takes on board ccarlen's comments

Comment on attachment 135962 [details] [diff] [review] Patch v0.3 - now uses InitWithNativePath r=ccarlen

Adding mkaply and delicates to cc list to check this patch isn't going to cause any issues on other OSes (OS2/BeOS/etc)

This should work fine on OS/2 although we already provide this functionality with an environment variable (MOZILLA_HOME)

Is that OS/2 specific?

Ah yes I can see it is from http://lxr.mozilla.org/seamonkey/source/xpcom/io/SpecialSystemDirectory.cpp#700 onwards

Adding disreali to cc to check for BeOS issues

ccing other BeOS gurus to check

Introduced new cmdline switch -MigrationOverride which with no arguments or "" migrates with a profile root based on the NS4.x profile's root or with a valid argument uses that as the profile root.

Also makes explicit that path is absolute and uses .Equals instead of !=

Comment on attachment 136186 [details] [diff] [review] Patch v0.4a - revised so new cmdline switch is now proceesed in MigrateProfile Requesting review

Why the change from using prefs to using nsICmdLineService? The impl of nsICmdLineService is in xpfe and it would be better to reduce that dependency from profile mgr backend instead of increasing it. Depending on the prefs service is better, IMO. Also, with the previous patch, it was nicely commented in all.js, so that it was discoverable by a power user. Since you didn't update the help text in nsAppRunner, how's anybody going to discover this? Also, updating the help text in nsAppRunner.cpp is only going to apply to apps built with that code (not embedding apps).

conrad: because these things aren't prefs. they don't have any meaning to a running application and have no business costing in memory footprint. apprunner help actually does get generated from commandline service stuff. you might need to register components to get it to work, but it does happen.

This compliments existing patch - wording might need tweaking.

timeless: We use the prefs widely for configuration settings. The small amount of memory taken up by these two prefs is much less evil than spreading nsICmdLineService dependencies into more profile backend code. Right now, that's pretty much limited to StartupWithArgs, which really should be removed from the profile mgr component and into app-level code. Ian: I still prefer the patch I already gave an r= to. Ask a super-reviewer for an opinion here and, if it's the other patch, I'll review it. CC'ing darin for his opinion.

ccing David, as an sr, for his opinion.

I'm with Conrad here - there are several prefs already that control profile migration, so any new behaviour should be controlled by prefs as well, for consistency's sake. Also, large installations that want to have a common install dir can just set it in defaults/pref/all.js along with whatever other prefs they customize.

Back to using prefs again. If behaviour is set to 2 and directory specified isn't absolute then we now revert to default location for OS (as per behaviour 0).

Comment on attachment 136186 [details] [diff] [review] Patch v0.4a - revised so new cmdline switch is now proceesed in MigrateProfile Cancelling old request

Comment on attachment 136287 [details] [diff] [review] Help Patch v0.4a for apprunner files Cancelling old request

Comment on attachment 136932 [details] [diff] [review] Patch v0.5 - tweaked version of patch 0.3 Requesting review

Comment on attachment 136932 [details] [diff] [review] Patch v0.5 - tweaked version of patch 0.3 r=ccarlen

Comment on attachment 136932 [details] [diff] [review] Patch v0.5 - tweaked version of patch 0.3 sr=bienvenu

Comment on attachment 136932 [details] [diff] [review] Patch v0.5 - tweaked version of patch 0.3 Requesting approval to check into 1.6beta - low risk enhancement

I think this kind of change is probably better to get in alpha or beta. Does anyone think this is near-zero risk enough to take in final?

it looks pretty safe to me, pretty close to zero risk.

Comment on attachment 136932 [details] [diff] [review] Patch v0.5 - tweaked version of patch 0.3 a=asa (on behalf of drivers) for checkin to Mozilla 1.6

Fix checked in.

I think this may be releasenote worthy. This has serious potential for bringing Thunderbird into the workplace.