Closed Bug 247427 Opened 16 years ago Closed 15 years ago

"pluginreg.dat" & "registry.dat" should be stored in %APPDATA%/Mozilla/Firefox

Categories

(Toolkit :: Startup and Profile System, defect, P3, critical)

x86
All
defect

Tracking

()

VERIFIED FIXED
mozilla1.8final

People

(Reporter: anonemoose, Assigned: benjamin)

Details

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 (ax)
Build Identifier: 

Recently the folder the FireFox stores Plugin & registry info changed from
"Phoenix" to "Mozilla/FireFox". But that implementation is not consistent in
regards to "pluginreg.dat" & "registry.dat" files.
The files "pluginreg.dat" & "registry.dat" should be also be placed in
%APPDATA%/Mozilla/Firefox. Now FireFox places them in %APPDATA%/Mozilla/ That is
a  big problem since the 2 files, registry.dat & pluginreg.dat, are also put in
that SAME location by Mozilla Suite/Netscape 7.1 ... This means u can not use
Mozilla Suite/Netscape 7.1 on the same machine as FF 0.9 as they will overwrite
each others versions "pluginreg.dat" & "registry.dat".

Note I am refering to pluginreg.dat & registry.dat and NOT the actual profiles's
data files (cookies.txt, prefs.js etc) which indeed are stored in
%APPDATA%/Mozilla/Firefox/Profiles .

I am using On Win98 OS. Can anyone confirm on other OS's

Reproducible: Always
Steps to Reproduce:


Actual Results:  
"pluginreg.dat" & "registry.dat" stored in %APPDATA%/Mozilla/

Expected Results:  
"pluginreg.dat" & "registry.dat" should be stored in preferably in 
%APPDATA%/Mozilla/Firefox.
obviously disregard my UA on the bug as I posted using FF 0.8
Flags: blocking1.0?
This bug applies to Linux as well -- mozver.dat and pluginreg.dat (in
~/.mozilla) are overwritten by Firefox 0.9.
Status: UNCONFIRMED → NEW
Ever confirmed: true
more info in this thread http://forums.mozillazine.org/viewtopic.php?t=85973
OS -> all per comment 2.
OS: Windows 98 → All
Flags: blocking1.0? → blocking1.0+
Is there a reason Firefox is not getting an Appdata dir of its own, rather than
association with Moz which it is being gradually separated from?

If Firefox is intended to be standalone as an App and from the Mozilla
predecessor, having data in a dir such as /mozilla/firefox/ is not geared for
clarity. 
Fixed on trunk and branch
Status: NEW → RESOLVED
Closed: 16 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
(In reply to comment #5)
> Is there a reason Firefox is not getting an Appdata dir of its own, rather than
> association with Moz which it is being gradually separated from?
> 
> If Firefox is intended to be standalone as an App and from the Mozilla
> predecessor, having data in a dir such as /mozilla/firefox/ is not geared for
> clarity. 

Its common practice to put users data in the
%APPDATA%/"OrganizationName"/"ProgramName"/ directory.
(In reply to comment #6)
> Fixed on trunk and branch

In what release of Firefox is (will be) the fix included?
(In reply to comment #8)
> (In reply to comment #6)
> > Fixed on trunk and branch
> 
> In what release of Firefox is (will be) the fix included?

I'd assume 1.0PR, since that's the next release.
Creating a new profile on the below-mentioned build once again places
registry.dat in %appdata%/Mozilla (as opposed to %appdata%/mozilla/firefox).
Pluginreg.dat remains in its proper place. Could somebody with appropriate
permissions please reopen this bug?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041001
Firefox/0.10
multiple users confirming wrong location
->REOPEN
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
for AVIARY builds that is, don't know about trunk
I can confirm that this is not fixed on the Aviary Branch as well (same problem
as comment 10). Removing the fixed-aviary1.0 keyword.
Keywords: fixed-aviary1.0
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
fresh install of 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041007
Firefox/0.10.1

pluginreg.dat resides under %APPDATA%/Mozilla/Firefox
cannot find registry.dat anywhere
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041014
Firefox/0.10

- Branch ZIP build
- Deleted old profile/app dir completely prior to install.

Results:

- pluginreg.dat in %APPDATA%/Mozilla/Firefox/
- registry.dat in %APPDATA%/Mozilla/

-----------------------
And my 2c, I think all products should go with the convention:

%APPDATA%/"OrganizationName"/"ProgramName"/

While Firefox/Thunderbird/Everything else reside on mozilla.org servers, I think
that should be the case. And even if theyre not to be quite honest.
It appears to me that this actually is fixed -- can someone please sort this out?
Using the 1.0 release on windows, if you use the -p command line option to move
the profile, or the PortableFirefox (http://portablefirefox.mozdev.org)
bootstraper to run firefox from a USB device, it still writes pluginreg.dat to
the application data folder of the machines hard disk.

Apart from talkback this seems to be the only corruption to the host machine
when you run firefox from a USB device.

Shouldn't these files be in the Firefox program directory, as they are for all
users?
(In reply to comment #18)
> Shouldn't these files be in the Firefox program directory, as they are for all
> users?

well at least with the instance of Plug-ins there is a bug filed for moving the
plug-ins to the profile so it would fit with

why different reg for different profiles... i suppose it keeps some profile
specific things in the registry not sure about that
(In reply to comment #18)
> Shouldn't these files be in the Firefox program directory, as they are for all
> users?
This problem seems to have morphed into something entirely different - the
original problem has been fixed. The files in question are now properly located in
C:\Windows\...\Mozilla\Firefox.

Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8a6) Gecko/20041207 Firefox/1.0+ ZIP
build with a totally clean install. Profile located in:
C:\Program Files\Mozilla Firefox\firefox\Users.

Profile.ini is placed in the location listed above.
Registry.dat can not be located.
Pluginreg.dat can not be located.

This should be marked as FIXED.
The big question is now, "Should profile.ini be located in 
C:\Windows\...\Mozilla\Firefox"?  I think not, but that is a whole new story -
Maybe a new bug?
Maybe this one should be marked "INVALID" since those files no longer exist (is
that right?).

In that case, I'd say do a new, more specific bug on the other issues.
There in %APPDATA%\Firefox on my box.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b)
Gecko/20050217 Firefox/1.0+

FIXED? WORKSFORME?
I confirm the entire Fred Collier's comment #18 with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050224
Firefox/1.0+
(new profile, no pre-existing %APPDATA%\Mozilla directory)
Flags: blocking-aviary1.1?
Sorry for bugspamming, but is this old issue ever going to be fixed? The
inconsistency between Firefox which creates profiles in
%APPDATA%\Mozilla\Firefox, Thunderbird (%APPDATA%\Thunderbird) and Mozilla is a
bit odd. Also, confirming with FF 1.0.1
Priority: -- → P3
Target Milestone: --- → Future
Flags: blocking-aviary1.1? → blocking-aviary1.1+
registry.dat is _still_ not in the %APPDATA%\Mozilla\Firefox folder, it's in
%APPDATA%\Mozilla\.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050421
Firefox/1.0+
Flags: blocking-aviary1.0.4?
Not the type of change we'd take on a bugfix branch.
Flags: blocking-aviary1.0.5? → blocking-aviary1.0.5-
Benjamin, is this really regressed or is this just old files floating around?  I
can't reproduce here.  Please add to the b4 blocker list if it has, or resolve
if it hasn't.
This is tested with a fresh install of: Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.8b3) Gecko/20050708 Firefox/1.0+

The pluginreg.dat is created in %APPDATA%/Mozilla/Firefox/, this file will
however not show up until a plugin has been installed and used (install Flash
Player and visit www.cnn.com).
 
The registry.dat is created in %APPDATA%/Mozilla/.
 - if you do a fresh install with no pre-existing profiles and let the installer
launch Firefox, which creates a new profile the registry.dat file is created.
 - if you have an existing profile or create one from the profile manager
without letting the installer start Firefox, then no registry.dat is created.
Can confirm Vignir's comment using Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.8b4) Gecko/20050722 Firefox/1.0+, fresh install via. installer
I can confirm Vignir's comment. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.10) Gecko/20050716. Tested on a new virtual PC as a new install with no
pre-existing profiles. I let the installer launch Fx and registry.dat was placed
in the Mozilla directory instead of in the Fx folder.

Why has this not been fixed? I have a mess on my host machine as I have Fx
1.0PR, Mozilla 1.6 and Netscape 7.2 on that machine. My profiles are constantly
being overwritten. When I installed Netscape the first thing I saw was a list of
my profiles for Fx and Mozilla. I have three profiles all used by all three
browsers. If I have Fx open using one profile and go to open Mozilla or
Netscape, I cannot choose the profile that Fx is using and vice versa. I am
unable to upgrade Mozilla from 1.6. If I do, I cannot run both Fx and Mozilla at
the same time. I like to have at least two browsers open at the same time.
 
On my W98SE box, this bug causes Mozilla and Fx to crash if I try to run them at
the same time. I have found that I can run Mozilla 1.5 and Fx 1.0PR together on
that box but if I upgrade Mozilla to 1.6 or above, I cannot run them together as
both will crash. 

On my host machine (XP Pro SP1a) my profiles on all three browsers are
constantly getting corrupted and I think this bug is the reason. This needs to
be fixed!    
I believe this is not a profile's issue, but a migrator's.

nsNetscapeProfileMigratorBase::GetProfileDataFromRegistry
(strictly speking, nsRegistry::Open in that fucntion)
creates registry.dat for some reason. I guess checking whether
the regfile exists or not before calling nsRegistry::Open
would fix this problem.
Attached patch Patch (obsolete) — Splinter Review
This patch would fix the problem described at comment #28
Attachment #191048 - Flags: review?(benjamin)
Comment on attachment 191048 [details] [diff] [review]
Patch

Good catch!

Since it is reasonably likely that the registry file may not exist, we
shouldn't be using the NS_ENSURE_TRUE macro for the "regFileExists" check (the
NS_ENSURE_* macros display a debug warning on failure); use

if (!regFileExists)
  return NS_ERROR_FAILURE;

instead
Attachment #191048 - Flags: review?(benjamin) → review-
Attached patch PatchSplinter Review
> we shouldn't be using the NS_ENSURE_TRUE macro
I see.
Attachment #191048 - Attachment is obsolete: true
Attachment #191226 - Flags: review?(benjamin)
Attachment #191226 - Flags: review?(benjamin) → review+
Attachment #191226 - Flags: approval1.8b4?
Attachment #191226 - Flags: approval1.8b4? → approval1.8b4+
Checking in nsNetscapeProfileMigratorBase.cpp;
/cvsroot/mozilla/browser/components/migration/src/nsNetscapeProfileMigratorBase.cpp,v
 <--  nsNetscapeProfileMigratorBase.cpp
new revision: 1.15; previous revision: 1.14
done
Status: REOPENED → RESOLVED
Closed: 16 years ago15 years ago
Resolution: --- → FIXED
Target Milestone: Future → Firefox1.1
Version: unspecified → Trunk
Status: RESOLVED → VERIFIED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.