[BLOCK] Unable to read in mail/news prefs

VERIFIED FIXED in M7

Status

()

Core
Preferences: Backend
P1
blocker
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: Scott MacGregor, Assigned: mcmullen)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
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.

Updated

19 years ago
Severity: normal → blocker

Comment 1

19 years ago
We'll need this fixed for today's release build.  Thanks, John.

Updated

19 years ago
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

Comment 2

19 years ago
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.

Comment 5

19 years ago
True..I tried that as well and it didn't work.

- rhp

Comment 6

19 years ago
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.

Comment 8

19 years ago
Created attachment 426 [details] [diff] [review]
A potential fix

Comment 9

19 years ago
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.

Comment 10

19 years ago
Works for me.
(Reporter)

Comment 11

19 years ago
I'm trying scott's patch out on linxu now.
testing puttermans patch right now
puttermans patch works for me on linux.
(Reporter)

Comment 14

19 years ago
scott's patch works for me on Linux.

Comment 15

19 years ago
Should we check in the patch before leaf spins today's release builds?  Safe to
do?

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 16

19 years ago
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.
(Assignee)

Comment 17

19 years ago
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.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 18

19 years ago
verified fixed

Comment 19

18 years ago
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.