Closed Bug 24954 Opened 25 years ago Closed 21 years ago

[deployment]Need ability to specify with -installer the Users directory

Categories

(Core Graveyard :: Profile: Migration, enhancement, P3)

x86
Other
enhancement

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.6beta

People

(Reporter: lchiang, Assigned: iannbugzilla)

References

Details

(Keywords: helpwanted, relnote, Whiteboard: [ADT3])

Attachments

(1 file, 7 obsolete files)

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.
Assignee: dbragg → racham
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.
Status: NEW → ASSIGNED
Target Milestone: M15
Severity: normal → enhancement
Target Milestone: M15 → M17
Target Milestone: M17 → M20
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...
Assignee: racham → ccarlen
Status: ASSIGNED → NEW
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.
Status: NEW → ASSIGNED
Setting milestone to mozilla0.9
Target Milestone: --- → mozilla0.9
*** Bug 67916 has been marked as a duplicate of this bug. ***
-> 0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
Marking as duplicate of bug 60734.

*** This bug has been marked as a duplicate of 60734 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
verify duplicate
Status: RESOLVED → VERIFIED
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.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Can we set the target milestone to mozilla0.9.7 or above ?
-> 0.9.9
Status: REOPENED → ASSIGNED
Target Milestone: mozilla0.9.1 → mozilla0.9.9
*** Bug 114085 has been marked as a duplicate of this bug. ***
This feature will benefit client deployment and distribution.
Summary: Need ability to specify with -installer the Users directory → [deployment]Need ability to specify with -installer the Users directory
-> 1.0
Target Milestone: mozilla0.9.9 → mozilla1.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.
Blocks: 124418
Keywords: nsbeta1
-> 1.0.1
Target Milestone: mozilla1.0 → mozilla1.0.1
ADT need info. Pls let us know how this impacts OEMs or other customers.
Whiteboard: [ADT Need Info]
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.
...
Keywords: nsbeta1helpwanted, nsbeta1+
Whiteboard: [ADT Need Info] → ADT3
Whiteboard: ADT3 → [ADT3]
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.
Blocks: advocacybugs
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.
Keywords: nsbeta1-
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.
Keywords: nsbeta1+
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
Target Milestone: mozilla1.0.1 → 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).
Attachment #135147 - Flags: review?(danm-moz)
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
Assignee: ccarlen → bugzilla
Status: ASSIGNED → NEW
Accepting
Status: NEW → ASSIGNED
Attachment #135147 - Flags: review?(danm-moz)
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.
Attachment #135147 - Attachment is obsolete: true
Attachment #135202 - Flags: review?(danm-moz)
Blocks: 55309
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.
Attachment #135202 - Flags: review?(danm-moz) → review+
Behaviour now spelt as Behavior
Attachment #135202 - Attachment is obsolete: true
Comment on attachment 135278 [details] [diff] [review]
Patch v0.2a - same as v0.2 except with American spellings

Carrying forward r= and requesting sr
Attachment #135278 - Flags: superreview?(alecf)
Attachment #135278 - Flags: review+
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
Attachment #135278 - Flags: superreview?(alecf)
Attachment #135278 - Flags: review?(ccarlen)
Attachment #135278 - Flags: review+
aiming
Target Milestone: Future → mozilla1.6beta
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
Attachment #135278 - Flags: review?(ccarlen)
Patch takes on board ccarlen's comments
Attachment #135278 - Attachment is obsolete: true
Attachment #135962 - Flags: review?(ccarlen)
Comment on attachment 135962 [details] [diff] [review]
Patch v0.3 - now uses InitWithNativePath

r=ccarlen
Attachment #135962 - Flags: review?(ccarlen) → review+
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?
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.
Attachment #135962 - Attachment is obsolete: true
Also makes explicit that path is absolute and uses .Equals instead of !=
Attachment #136184 - Attachment is obsolete: true
Comment on attachment 136186 [details] [diff] [review]
Patch v0.4a - revised so new cmdline switch is now proceesed in MigrateProfile

Requesting review
Attachment #136186 - Flags: review?(ccarlen)
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.
Attachment #136287 - Flags: review?(ccarlen)
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).
Attachment #136186 - Attachment is obsolete: true
Attachment #136287 - Attachment is obsolete: true
Comment on attachment 136186 [details] [diff] [review]
Patch v0.4a - revised so new cmdline switch is now proceesed in MigrateProfile

Cancelling old request
Attachment #136186 - Flags: review?(ccarlen)
Comment on attachment 136287 [details] [diff] [review]
Help Patch v0.4a for apprunner files

Cancelling old request
Attachment #136287 - Flags: review?(ccarlen)
Comment on attachment 136932 [details] [diff] [review]
Patch v0.5 - tweaked version of patch 0.3

Requesting review
Attachment #136932 - Flags: review?(ccarlen)
Comment on attachment 136932 [details] [diff] [review]
Patch v0.5 - tweaked version of patch 0.3

r=ccarlen
Attachment #136932 - Flags: review?(ccarlen) → review+
Comment on attachment 136932 [details] [diff] [review]
Patch v0.5 - tweaked version of patch 0.3

sr=bienvenu
Attachment #136932 - Flags: superreview+
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
Attachment #136932 - Flags: approval1.6b?
Attachment #136932 - Flags: approval1.6b?
Attachment #136932 - Flags: approval1.6b-
Attachment #136932 - Flags: approval1.6?
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
Attachment #136932 - Flags: approval1.6? → approval1.6+
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago21 years ago
Resolution: --- → FIXED
I think this may be releasenote worthy.

This has serious potential for bringing Thunderbird into the workplace.
Keywords: relnote
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: