Closed Bug 247427 Opened 16 years ago Closed 15 years ago
.dat" & "registry .dat" should be stored in %APPDATA%/Mozilla/Firefox
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
This bug applies to Linux as well -- mozver.dat and pluginreg.dat (in ~/.mozilla) are overwritten by Firefox 0.9.
more info in this thread http://forums.mozillazine.org/viewtopic.php?t=85973
OS -> all per comment 2.
OS: Windows 98 → All
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
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.
16 years ago
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)
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
15 years ago
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+
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.
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-
> we shouldn't be using the NS_ENSURE_TRUE macro I see.
Attachment #191226 - Flags: review?(benjamin) → review+
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 ago → 15 years ago
Resolution: --- → FIXED
Target Milestone: Future → Firefox1.1
Version: unspecified → Trunk
You need to log in before you can comment on or make changes to this bug.