when I create a new profile, (not migrate it) I get this: ~/.mozilla/<profile>/panels.rdf ~/.mozilla/<profile>/en-US/panels.rdf with a migrate profile, I just get ~/.mozilla/<profile>/panels.rdf one of those is wrong. for en-US users, it doesn't hurt anything. but I'm worried that for other locales, it means they get the default english rdf files. assigning to racham to investigate.
Hi, Seth: The 2nd one is not used. They are copied over to new profile because profile code recurively copies all files under bin/defaults/profile/*. This will happen when "language/region" is not explicitly selected. It will not cause malfunction of the product; redundent files are copied -- that is all.
The first case Seth mentioned was a side-effect of RecursiveCopy we do to sump all default profiles into a newly created profile directory. When the localization scheme came in, we added some locale folders under default profile directory and they are also started getting copied along with other default files. So, we have some additonal folders sitting in there. Utlimately, all we access are the files under the profile directory and any locale subfolders at runtime. So, presence of en-US is not harmful anyway as tao mentioned. This is the case for the users who skip the Region Selection during the new profile creation. This is a bug and we need to avoid copying redundant files. For the users, who select a particular region, the directory from which the default files to be copied will be that region directly (say, if a user selects en-US region, we ask profile code to copy default files from the en-US folder..not one onelevel above like for all default cases) and we won't have copy any additonal folders here. Coming to the migrated profile cases, we simply pick the files from defaults/profile folder. We will always have localized content in this folder depending on the locale build you downloaded. If you are ja user and downloaded, en-Us build, you will get default en-US profile files and if you are a ja user and downloaded japanese build you will get all japanese default files into your migrated profiel directory. So, it really depends on the build user gets and that's users choice. We provide default files depending on his locale choice. We could do smarter things like finding out locale of the machine and get those default files and that is subjected to discussion again if we have to give the user who downloaded a english build, default japanese profile files. So, I think this bug should not be a major concern for rtm.
Status: NEW → ASSIGNED
rtm-, no harmful effects to user experience.
Tao, Is there an interaface in the locale services to determine whether a given a string is any of the locale names...? If there is one, that would help us solve this problem with ease as we can do that check on the directory name and skip those dirs in the recusrive copy....
Doing a mass reassign to Conrad Carlen. Conrad is going address all current and upcoming profile manager issues. Please do not hesitate to involve me in any of the issues.
Assignee: racham → ccarlen
Status: ASSIGNED → NEW
Tao, I still have the same question that Bhuvan asked on 2000-11-30. It would be good to get rid of this file clutter. If I could identify a locale sub-dir in the defaults dir, I could skip copying it.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
Hi, Bhuvan and Conrad: It seems to me what you really need is a list of installed locale porvider names. There is no single api to provide such information as far as I know. You can retrieve this information from chromeRegistry, though. You can consult hyatt or waterson for how to get this info.
Target Milestone: mozilla0.9 → mozilla1.0
*** Bug 78472 has been marked as a duplicate of this bug. ***
this bug has a broader impact - it seems - since there are copies of boomarks.htm, etc. etc. And also userChrome.css and userContent.css are getting placed in the wrong .../chrome directory rendering them useless
> And also userChrome.css and userContent.css are getting placed in the wrong .../chrome That's bug 37642. It has nothing to do with profile mgr but is a makefile problem.
In particular, see attachment 32917 [details] [diff] [review] on that bug. That will fix the problem of files you mention being in the wrong place.
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Target Milestone: mozilla1.0.1 → Future
3 years ago
This bug is filed in a bugzilla component related to pre-Firefox code which no longer exists. I believe it is no longer relevant and I am therefore closing it INCOMPLETE. If you believe that this bug is still valid and needs to be fixed, please reopen it and move it to the Toolkit:Startup and Profile System product/component.
No longer blocks: 1243899
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.