Closed
Bug 78472
Opened 23 years ago
Closed 23 years ago
new profiles come with strange directory structure
Categories
(Core Graveyard :: Profile: BackEnd, defect)
Tracking
(Not tracked)
People
(Reporter: andreww, Assigned: ccarlen)
Details
steps to replicate: get macbuild 2001050104 create a new profile with this build now inside this profile I see: bookmarks.html Cache/ chrome/ etc. etc. but now I also see a new directory called "US" at this level. Inside "US" I see bookmarks.html chrome/ default-messages.rdf localstore.rdf mimetypes.rdf panels.rdf search.rdf and there are files inside this inner chrome directory as well. It looks like these files are getting created in the wrong location
Comment 1•23 years ago
|
||
Seeing this on Linux too. Build 2001-05-01-08. More data: 1) start with -profilemanager 2) Create a brand new profile 3) before starting it has: US/ bookmarks.html localstore.rdf mimeTypes.rdf panels.rdf search.rdf US/ has: bookmarks.html localstore.rdf mimeTypes.rdf panels.rdf search.rdf 4) Start mozilla 5) Now we have: Cache/ US/ cert7.db history.dat localstore.rdf panels.rdf search.rdf NewCache/ bookmarks.html chrome/ key3.db mimeTypes.rdf prefs.js secmod.db and US/ has: bookmarks.html localstore.rdf mimeTypes.rdf panels.rdf search.rdf and chrome/ has: user-locales.rdf user-skins.rdf Note the lack of a userChrome.css/userContent.css anywhere
OS: Mac System 9.x → All
Comment 2•23 years ago
|
||
The reason I mention user*.css is that they _are_ in mozilla/profile/defaults/profile/chrome and mozilla/profile/defaults/profile/US/chrome So obviously the chrome/ dir is no longer being created from these dirs....
Comment 3•23 years ago
|
||
Almost certainly not a build config bug.... Here is what I'm seeing. We create a new profile. For some reason don't create a chrome dir in it. Then when we try to copy the CSS files to the chrome dir after it's created in nsChromeRegistry::GetProfileRoot, we fail. Looks like an XP Apps issue... reassigning. ccing dr in case he knows something
Assignee: cls → pchen
Component: Build Config → XP Apps
QA Contact: granrose → sairuh
Comment 4•23 years ago
|
||
->profile mgr backend.
Assignee: pchen → ccarlen
Component: XP Apps → Profile Manager BackEnd
QA Contact: sairuh → gbush
Assignee | ||
Comment 6•23 years ago
|
||
Two things here: (1) The "US" directory with copies of the top-level files is there because when a profile is made and a locale is not specified, the contents of the top-level profile defaults are copied recursively into the new profile dir. If a locale is specified when the profile is created, the contents of that specific locale sub-dir are copied recursively and you don't end up with an extra level of files. In any case, the extra level of profile defaults is not harmful and is not a new situation. There is a dup of this bug somewhere. (2) About the /chrome dir in profile defaults. That was added recently - I didn't know about until right now. On my Mac build from this morning, there is a /chrome dir in defaults/profiles whereas in my Linux build from this morning there is not. If it's not there, it's not gonna get copied. That seems to be a build problem.
Assignee | ||
Comment 7•23 years ago
|
||
The bug I mentioned is bug 56590. The name "en-US" has changed since then.
Comment 8•23 years ago
|
||
The chrome directory was added as part of the fix to bug 37642. This used to work. It broke sometime in the last few weeks.
Comment 9•23 years ago
|
||
OK. The reason the .css files are not being copied is that the paths in a Makefile.in are wrong. I've reopened bug 37642 to deal with that issue.
Assignee | ||
Comment 10•23 years ago
|
||
Part of this bug is a dup of bug 56590. The other part is invalid because it has nothing to do with profile mgr. Marking as duplicate. *** This bug has been marked as a duplicate of 56590 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•