Closed Bug 18989 Opened 21 years ago Closed 19 years ago

Viewer creates a file called 'default_prefs.js' in the application directory

Categories

(SeaMonkey :: Preferences, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED WONTFIX

People

(Reporter: sfraser_bugs, Assigned: bnesse)

Details

When I run mozilla, at some point it creates a file called 'default_prefs.js' in
the appliction directory. Such a file at this level is unsightly; it should
either not be there at all, or is should be placed in a subfolder (like defaults/
prefs).
Status: NEW → ASSIGNED
Target Milestone: M13
Target Milestone: M13 → M14
QA Contact: paulmac → sairuh
spam: in my testing realm, so reassigning qa contact to me, en masse.
Changing tfv to M15
Target Milestone: M14 → M15
Moving all libPref component bugs to new Preferences: Backend component.  
libPref component will be deleted.
Component: libPref → Preferences: Backend
Target Milestone: M15 → M17
Target Milestone: M17 → M18
prefs to mcafee
Status: ASSIGNED → NEW
Target Milestone: M18 → ---
argh... didn't work the last time. pardon the spam. ->mcafee
Assignee: neeti → mcafee
Component: Preferences: Backend → Preferences
dveditz
Assignee: mcafee → dveditz
It's actually viewer that creates this file, probably because it knows nothing 
about profiles.
Summary: Mozilla creates a file called 'default_prefs.js' in the application directory → Viewer creates a file called 'default_prefs.js' in the application directory
It seems that when the prefs.js file can not be created
Mozilla won't start. I'm seeing this problem on Solaris
and zh, zh.GBK locales.

It's interesting that when the locale is zh or zh.GBK,
Mozilla seems to try to create the file. But when fails,
Mozilla won't start.
Blocks: 60916
It seems that default_prefs.js will be created when creating user's
profile directory fails. In zh and zh.GBK, the converters have problems
so the profile directory could not be created.

http://bugzilla.mozilla.org/show_bug.cgi?id=60823

It's converter bugs. This bug itself does not block the exact
problem on Solaris. So I'll remove 60916 from block field.
No longer blocks: 60916
I think Brian owns prefs now. I know I don't
Assignee: dveditz → bnesse
The code that causes this is in useDefaultPrefFile() a shortened version is below:

{
// Anything which calls NS_InitXPCOM will have this
rv = NS_GetSpecialDirectory(NS_APP_PREFS_50_FILE, getter_AddRefs(aFile));

if (!aFile) {
  // We know we have XPCOM directory services, but we might not have a provider
  // which knows about NS_APP_PREFS_50_FILE. Put the file in
  // NS_XPCOM_CURRENT_PROCESS_DIR.
  rv = NS_GetSpecialDirectory(NS_XPCOM_CURRENT_PROCESS_DIR,
                              getter_AddRefs(aFile));
  if (NS_FAILED(rv)) return rv;
  rv = aFile->Append("default_prefs.js");
  if (NS_FAILED(rv)) return rv;
}

It looks to me like some kind of a fallback position for embedding, but that's
just a guess.

It does strike me as odd that a file is created though. As far as I can tell
nsIFile::Append() shouldn't cause a file to be created.
Changing platform
Hardware: All → Macintosh
OS: Mac System 8.5 → All
Hardware: Macintosh → All
This is working as it was designed to. After failing to find the preferred
directory, the code falls back to a known location (the application directory.)
After reviewing the list of potential fallback candidates it seems like
NS_XPCOM_CURRENT_PROCESS_DIR is a pretty reasonable solution to me.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
okay, v.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.