8197 - [BLOCK] Unable to read in mail/news prefs

Status: VERIFIED FIXED

(Core :: Preferences: Backend, defect, P1)

Description

[Scott MacGregor]

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.

Comment 1

[lchiang]

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

Comment 2

[don]

John, did anything big change?

Comment 3

[(not reading, please use [e-mail] instead)]

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.

Comment 4

[(not reading, please use [e-mail] instead)]

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

[rhp (gone)]

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

- rhp

Comment 6

[scottputterman]

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.

Comment 7

[(not reading, please use [e-mail] instead)]

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

[scottputterman]

Attachment: A potential fix

Comment 9

[scottputterman]

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

[rhp (gone)]

Works for me.

Comment 11

[Scott MacGregor]

I'm trying scott's patch out on linxu now.

Comment 12

[(not reading, please use [e-mail] instead)]

testing puttermans patch right now

Comment 13

[(not reading, please use [e-mail] instead)]

puttermans patch works for me on linux.

Comment 14

[Scott MacGregor]

scott's patch works for me on Linux.

Comment 15

[lchiang]

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

Comment 16

[scottputterman]

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.

Comment 17

[mcmullen]

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.

Comment 18

[Paul MacQuiddy]

verified fixed

Comment 19

[leger]

Moving all libPref component bugs to new Preferences: Backend component.  
libPref component will be deleted.