Here's the initial report from rhp: > I can't get today's build to read my mail prefs correctly and show my > mail servers. Did something change? Is anyone else running properly > with a fresh build? David Bienvenu was up to date in mailnews this morning and things were running fine. He then updated outside of mailnews and encountered the problem as well. More emails are posted to n.p.m.builds Assigning to mcmullen to start off with as it looks like there were some prefs changes last night.
We'll need this fixed for today's release build. Thanks, John.
OS: Windows NT → All
Priority: P3 → P1
Summary: QA BLOCKER: Unable to read in mailnews prefs → [BLOCK] Unable to read in mail/news prefs
Target Milestone: M7
John, did anything big change?
I had the same problem on linux (fresh build, 9am PST). then I removed my registry (~/.mozilla/registry on linux) and when I start up, it works again. rhp, try that. perhaps the profile manager changes that landed yesterday require a removal of the registry? adding racham and selmer to the cc list.
I take that back. I started up, saw the problem rhp reported exited. remove my registry started up, it used Default and in my Default dir I had a prefs50.js file, and that's why it worked. exited. start up again, got the profile manager, entered sspitzer as the profile. exited. started up again, and it tried to use ProfileName : sspitzer ProfileDir : /home/sspitzer/.mozilla/sspitzer got the problem rhp reported again. so it's XP, and removing the registry doesn't help.
True..I tried that as well and it didn't work. - rhp
It looks like the problem might be in nsPref::ReadUserPrefsFrom(nsIFileSpec* inFile) where the line if ((NS_SUCCEEDED(mFileSpec->exists(&exists)) && exists) || pref_OpenFileSpec(mFileSpec, PR_TRUE, PR_FALSE, PR_FALSE, PR_TRUE) != PREF_NOERROR) rv = NS_ERROR_FAILURE; returns NS_ERROR_FAILURE if the file exists. I think we want a '!' in front of the first condition. I'll try that out.
I've also started to debug this. main calls nsPref::useDefaultPrefFile which calls nsPref::ReadUserPrefs at nsPref.cpp:459 nsIFileSpec* prefsFile = NS_LocateFileOrDirectory(nsSpecialFileSpec::App_PreferencesFile50); the result of prefsFile after this call looks really suspicious. using the debugger, I found that: ((nsFileSpec *prefsFile)->mPath.mData)->mRefCount = 0 ((nsFileSpec *prefsFile)->mPath.mData)->mLength = 0 but since prefsFile is not null, we'll try to open and file. in NS_LocateFileOrDirectory (see nsIFileLocator.h) after the call to rv = locator->GetFileLocation(selector, &spec); rv is 0, but spec is as I described above (refcount = 0, length = 0) I'm continue to debug, and see why that is.
My comment got erased. The patch I attached works for me and makes it so I can see my folders. Could someone else try this. I'm not sure the gErrorOpeningUserPrefs is correct, but it seems the right thing. It might affect other code I don't know about though. However, if we don't do it there, we should do it in pref_OpenFileSpec.
Works for me.
I'm trying scott's patch out on linxu now.
testing puttermans patch right now
puttermans patch works for me on linux.
scott's patch works for me on Linux.
Should we check in the patch before leaf spins today's release builds? Safe to do?
Status: NEW → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
I checked it in. I ran the browser and nothing bad happened and I brought up the preferences dialog and nothing bad happened so this fix should be safe until John changes it to what he wants. At the least it'll make it so we can work on Messenger and QA can test it.
Thank you all for fixing this, and my apologies to all concerned. This was all rearranged to allow the profile wizard to come up with default prefs read in but user prefs not read in. In addition to this change, I "fixed" the pref API so that it uses the COM- friendly object nsIFileSpec, instead of nsFileSpec. The logic here got mangled in the process.
Moving all libPref component bugs to new Preferences: Backend component. libPref component will be deleted.
Component: libPref → Preferences: Backend
You need to log in before you can comment on or make changes to this bug.