Closed Bug 296890 Opened 19 years ago Closed 19 years ago

XUL.mfl (FastLoad File) is not stored in specified Profile location

Categories

(SeaMonkey :: Startup & Profiles, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 292075

People

(Reporter: therubex, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050603
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050603

XUL.mfl (FastLoad File) is not stored in the user specified Profile location.

XUL.mfl (FastLoad File) is stored the Default Profile location irrespective of
the User Specified Profile location.

Reproducible: Always

Steps to Reproduce:
1. Download Mozilla
2. Run installer (mozilla-win32-installer.exe)
3. Exit Mozilla
4. Run Profile Manager.
   Delete the default Profile that is automatically created.
   Create Profile.  Specify name.
   Choose Folder...  Select a non-default location.  C:\WLIB\Mozilla\USERS, works.
   Finish.
   Exit.
Actual Results:  
User specified Profile directory is created.

XUL.mfl & \Cache\ are created in ...
C:\Documents and Settings\<Windows login/user name>\Application
Data\Mozilla\Profiles\<Profile name>\

Expected Results:  
XUL.mfl & \Cache\ should have been created in ...
C:\WLIB\Mozilla\USERS

Viewing Preferences | Advanced | Cache -> Cach Folder Location:, the User
specified Cache location is shown.  But that is not where it is located.

Selecting the Choose Folder box in the dialog, then OK that same selection, does
result in the Cache reverting to the specified location (upon restart).

If XUL.mfl is deleted, or manually copied into the User specified Profile
location, upon starting Mozilla, the file is deleted, & a new copy placed in the
Default Profile location rather then remaining in the User specified Profile
location.

With this happening, it makes it far more difficult & confusing to, 1) trying to
keep some semblance of order to things, & 2) it makes sharing a profile -
between User logins & or OS's more difficult. Also, when trying to clean up a
buggered Profile, XUL.mfl is one typical file that you would just go &
automatically delete. Now with it sitting alone in its own little place, it
makes it just that much more difficult to both realise that it even exits & to
delete it.

Further on the sharing of Profiles. With 1.8, each User (in XP) ends up with
their own copy of XUL.mfl, cause they are not using what previously had been the
single common copy as it had been in the past. Also note, that I do not & would
not try sharing Profiles simultaneously.
Other thoughts here:

"XUL.mfl file should be placed in Mozilla Cache"
https://bugzilla.mozilla.org/show_bug.cgi?id=130041
Version: unspecified → Trunk
with current SeaMonkey 1.8 branch and trunk builds on W2K/WXP the xul.mfl is
created under 
%USERPROFILE%\Local Settings\Application Data\Mozilla\Profiles\[profile name]\
(for English locale) and not in the profile folder itself, that was intended. 

For Firefox builds it is under
%USERPROFILE%\Local Settings\Application
Data\Mozilla\Firefox\Profiles\[random].[profile name]\
Actually, XUL.mfl and Cache are supposed to be stored in your Local Settings
folder. This is by design (sorry I don't remember the relevant bugs).
(In reply to comment #3)
> Actually, XUL.mfl and Cache are supposed to be stored in your Local Settings
> folder. This is by design (sorry I don't remember the relevant bugs).

Bug 74085, patch from Bug 291033

*** This bug has been marked as a duplicate of 292705 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
(In reply to comment #5)
> 
> *** This bug has been marked as a duplicate of 292705 ***

I guess something went wrong ... Bug 292705 is a Firefox bug about prefs ("After
clicking "Edit Options" in a notice bar, the Preferences window reopens after
pressing OK")
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Doh! Used cut-and-paste this time...

*** This bug has been marked as a duplicate of 292075 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.