141780 - [RFE] Need a means to specify where registry.dat is stored.

Status: VERIFIED WORKSFORME

(Core Graveyard :: Profile: BackEnd, enhancement)

Description

[Cyrus Patel]

With the (Moz) profile manager its possible to specify where the files that 
make up a profile are stored. However, the Profile Manager's own file (ie the
file that records where the profile directories are) is always
%USERPROFILE%\Application Data\Mozilla\registry.dat

Might it be possible to have a (registry or environment or similar) setting 
that tells Moz that the registry.dat is elsewhere?

Aside: As I happended to find out today, registry.dat is not simply a record of
where all the profiles are, but also contains machine-specific information, and
among other things, a record of which plug-ins are installed. If I understand 
the purpose of Moz profiles correctly, this information should not be there! If
the user has an (NT) roaming profile that plug-in information could be wrong.

Comment 1

[Matthias Versen [:Matti]]

-> Profile Manager

Comment 2

[Scott Tran (Wildcard)]

Status -> NEW

Comment 3

[Aaron Kaluszka]

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

Comment 4

[Pete Boyd]

I'm about to setup Mozilla in a Windows 2000 roaming situation. I've previously
setup Netscape 4.7x similarly on NT4. I'm trying to understand what differs
between the two apps in relation to this way of using them. it seems Mozilla's
%APPDATA%\Mozilla\registry.dat replaces Netscape 4.x's %WINDIR%\NSREG.DAT and is
a vast improvement on the situation because it lives whereever the user's
profile lives rather than needing to exist locally to each workstation, and an
instance of it exists for each user rather than one for all users

so, Cyrus, what are you hoping to gain from storing REGISTRY.DAT elsewhere if
you can already move the Windows profile itself elsewhere? (I can't see what
you'd gain, but if you can then I'm also interested in knowing it for my own
situation)

wouldn't a workstation registry setting defeat the objective of moving as many
Mozilla specific references from the workstation to the server?

concerning your aside, this should be filed as a seperate bug.
(isn't the "record of which plug-ins are installed" in REGISTRY.DAT not a
plug-in directory but a result of having the MIME types declared there? I can't
remember how I got around having the specific directories listed in this file
with NS4 but I presume it was done by always installing the plug-ins on the
server to the same drive letter that all the workstations could also see, i.e.
install to P: instead of C:, where P: is the PROGRAMS volume that is Shared as P:)

Comment 5

[Conrad Carlen (not reading bugmail)]

I agree with comment #4.

As far as the list of installed plugins, this is just a cache. It helps the
plugin loader load plugins faster by associating with each plugin file, the
plugin info for it (which takes time to gather). If the file does not exist
between locations, the plugin info will just be re-gathered from the plugin file
which does exist. Either way, regardless of this cache, all plugin locations are
scanned. Using the same cache between different locations defeats the
performance benefit the cache, but it does not cause incorrect plugin loading.
That bug should be filed against the plugin loader though - that's what
maintains that data in the registry.

dp - correct me if I'm wrong.

Comment 6

[Cyrus Patel]

my comment re: roaming profiles was an "aside", and had nothing to do with
having a "Need a means to specify where registry.dat is stored". 

As you point out, the move from the old %WINDIR%\nsreg.dat to the 
%USERPROFILE%\...\registry.dat is a vast improvement. Which is why I was so 
surprised to find that Moz still stores machine-specific config info (ie the 
location and function of plug-ins) in registry.dat. Even more amazing to me 
was the discovery that Moz is storing machine-specific configuration data that 
was originally obtained _dynamically_ (ie, the presence of the JRE plug-in), 
and that there is no practical reason why this information can't be obtained 
at run-time for all future sessions as well. I really don't know what Moz is 
doing with this plug-in record, or how it deals with plug-ins that "disappear", 
but I did find this behaviour worth noting. Yes, maybe this behaviour needs to 
be filed as a bug, but ATM I'd be the wrong person to do that since all my 
workstations are identically configured, and as such I wouldn't be able to 
tell what the effect might be (if any). I'll keep it in mind the next time I 
set up a machine from scratch.

With respect to having a "Need a means to specify where registry.dat is stored":

The vast majority of the accounts here are generated dynamically when a user 
logs in. The authentication and "real" login is to a NetWare file server, the 
local/workstation account is essentially a guest account. As such, the NT 
profile is based off of the 'Default User' account and is non-persistant.

The problem therefore was the need to find a way to store the _profile_ 
(prefs.js et al) somewhere persistant, and NOT (as I thought) the need to 
specify where registry.dat is stored. 

Once that was clear, so was the solution: Have registry.dat (which would be 
same for all users) point to some Moz profile in the user's home dir, ie 
generate a registry.dat thats pointing to (say) M:\xyz\, and where M:\xyz\ is 
actually a map to SYS:/USER/%NWUSERNAME%/xyz/

I was obviously not wide awake at the time I filed this bug. :). 

Comment 7

[Cyrus Patel]

Ok, quick checks to see what the deal with plugins+registry.dat is.

Test 1: deleted my registry.dat, created a new one with the Profile Manager, 
started Moz, and then immediately quit it. The registry.dat still had no record 
of the JRE even though the relevant dlls are in the plugins directory.

Test 2: Same as test 1, but did an about:plugins before quitting. Voila, JRE is 
now recorded. 

Test 3: Same as test 2, then quit, deleted the plugins, restarted, did a new 
about:plugins, quit. JRE is still recorded in registry.dat. Restarted, 
looked at about:plugins, JRE is not listed (as expected). Visit java.sun.com, 
got a "Click here to get the plugin" (as expected). Quit Moz. Looked at 
registry.dat, JRE is still recorded. Put the JRE .DLLs back in the plugins 
directory, revisited java.sun.com (without doing an about:plugins first), and 
Java still works.

Summary: 1) Moz updates its internal info about plugins _only_ when the user 
does an about:plugins. Simply putting them into the plugins directory is not 
sufficient. A rescan is not initiated when previously recorded plugins are not 
found. A (re-)scan is not initiated when Moz starts up (not even a 
filename/filedate check apparently). 
2) Once added, a plugin record is _never_ removed from registry.dat. There may 
be multiple entries for the same mimetype. If the Moz application directory 
changes, the registry.dat will still have entries from the old path.
3) Deleting a plugin does have any negative side-effects other than still 
having an obsolete entry in the registry.dat.

Comment 8

[Suresh Duddi (gone)]

JRE might be special. In general, a scan for plugins on all location are done
everytime we startup and cache is revalidated if timestamp changes.

Comment 9

[neeti]

cc'ing peterl

Comment 10

[Peter Lubczynski]

See bug 109739 for a patch to clean up "plugin caching"

Comment 11

[K'Trina Medina]

Verified WFM

Comment 12

[Asa Dotzler [:asa]]

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