144712 - RFE: mozilla needs a way to specify the parent folder of the profile folders

Status: RESOLVED WONTFIX

Description

[Jonathan Wilson]

Basicly, if bug 12911 was fixed and mozilla was using relative pathnames for all
components of a profile, it would then be possible to implement relative profile
pathnames.
Once thats in place, then you add a new setting thats global for mozilla and is
stored somewhere that tells mozilla to look in folder xyz for profiles instead
of (for example) c:\documents and settings\username\application
data\mozilla\profiles.
Each folder under the folder you specify would be then treated as a profile and
offerd for selecton in the profile manager. mozilla would inspect each folder to
identify if it is in fact a profile (by checking that prefs.js is there and can
be read perhaps)
This would allow you to share a profile between different operating systems or
different PCs.
Roaming profiles could also use this same feature in that every user is given a
profile folder on <somenetworkdrive>\profiles\username that is readable and
writeable by them.
Each machine that needs to access the roaming profiles would have the setting
for profile folders set to <somenetworkdrive>\profiles
When the user loads up the browser, it would go to <somenetworkdriver>\profiles
and check each profile folder to identify if its a profile or not (as specified
above). Profile folders that it cant read (i.e. everyones but those that whoever
is logged in has access to) wouldnt be displayed.
Another thing you could add is a setting that, when set one way would tell
mozilla to scan, when set the other way would tell it to prompt the user for the
name of a profile to load from whatever "profile folder" mozilla was configured
to use.
In the case where the user has a home folder on a server, you can just "mount"
that folder over the network as a drive letter (on windows) or a path (on unix).
Each users home folder would get mapped to the same path at login somehow (on
windows its easy to do) then the "profile path" would be set to that constant path.

Comment 1

[Jonathan Wilson]

oops, that shouldnt be bug 12911 in the earlier comment that should be bug 137006.
marking 137006 as a dependancy

Comment 2

[Pete Boyd]

see bug 141780 (this appears to be a duplicate of that bug)
and also checkout its comment #4:
http://bugzilla.mozilla.org/show_bug.cgi?id=141780#c4

"Another thing you could add is a setting that, when set one way would tell
mozilla to scan, when set the other way would tell it to prompt the user for the
name of a profile to load from whatever "profile folder" mozilla was configured
to use."
this is covered by Roaming Profiles bug 124029

Comment 3

[Jonathan Wilson]

124029 is about implementing 4.x style roaming profiles which are totally
different things to what I describe here.
141780 isnt a duplicate as far as I can tell from reading it, its related though.

let me explain how this would work. (pretend for a moment that 137006 has been
fixed and that all profile components are using relative paths)
1.user installs mozilla under one operating system and creates a profile. That
profile goes in a folder, lets call it x. under x will be profilename\xyz.slt
2.user installs mozilla under second operating system or on second PC. User then
uses new profile manager setting (could be stored in registry.dat) and sets it
to the full path (may be a network path like \\computer1\c\xyz, dont know if
mozilla reads those though) to folder x as seen by computer 2\operating system
2. Profile manager running under computer 2 or operating system 2 then scans the
path provided, scans each subfolder to identify if its a valid profile or not
(one possible way to check is to read prefs.js from profile and somehow check
that its valid)
Then all valid profiles are displayed and the user selects one, just like if it
was in the local location for profiles. If a new profile shows up, it will be
picked up by the next startup scan.
Mozilla will use the selected profile and read and write all data from/to it.

another case of this would be when the user is on a network and has, say ,a
writable home folder mapped to a drive letter or path or whatever. When the
account is created, a default profile of some kind, perhaps customized to the
user for email and stuff, is copied to the home folder. Then all machines on the
network are setup to use whatever the home folder is mapped to as the "profile
root folder" I am talking about.

The final case would be where the profile folders are all stored on the local
network server like the second case but they are in some central repository for
example \\computer\profiles and then you have a folder yourname under that with
the xyz.slt folder under that. This is assuming that there isnt a network map
directly to \\computer\profiles\yourname set up already. In this third case, you
might not want to have it do the scan (especially if there are many profiles) so
you have an extra checkbox or option that, when checked, tells profilemanager
not to scan but instead to ask the user to input the profilename (possibly you
could also have a 3rd option that would use the username from the windows
environment to find the profile i.e. profilename = username). After its gotten
the profilename from the environment or the user, it would load that profile
from the "profile base directory" specified in the settings.

Note that all this is based on what I understand from a windows perspetive (I
havent used mozilla on mac or unix so I cant speak about the profile code on
those platforms)

just to explain a bit more, on XP, all profiles go into c:\documents and
settings\my username\application data\mozilla\profiles
The "profile base directory" that this bug specifies a means of changing is that
base folder (which in turn has all profile folders)

Comment 4

[Pete Boyd]

I thought that what you were asking for had been discussed as part of providing
Mozilla Roaming Profiles; it isn't exactly what Roaming Profiles is but this
procedure of loading a profile from a location is covered by the work being done
on Roaming Profiles, or so I'd thought. and that would provide solution to some
of your request; but it wouldn't provide the ability for Mozillas on differing
operating systems to automatically scan for profile directories below a given
folder, but I think the ability to load a given profile from a given location
covers this well enough as a workaround

the reason I pointed to comment # 4 of bug 141780 is because I thought that,
atleast under Windows NT4/2000/XP, as Mozilla uses the Windows Profile
directory, and as you are able to move that directory to wherever you want, then
you are less likely to need to move the Mozilla profile directory independently
of this

maybe this still doesn't do it for you :)

Comment 5

[Franck Meckum]

It would be nice to pass the location of all profiles as parameter or via 
registry/configfile located in the mozilla installation directory.
The profiles should be password-protected too :)

e.g.:
mozilla --profiles-home=D:\common\mozilla\profiles --profile=my_name (--
password=xyz)
thunderbird --profiles-home=D:\common\mozilla\profiles --profile=%USERNAME%

this would lead to look for the profile under 
D:\common\mozilla\profiles\my_name\