Closed
Bug 58327
Opened 24 years ago
Closed 22 years ago
Make profiles dir names configurable (fix --enable-homedir, now called --with-user-appdir)
Categories
(Core :: XPCOM, defect)
Core
XPCOM
Tracking
()
RESOLVED
FIXED
mozilla1.5alpha
People
(Reporter: BenB, Assigned: dougt)
References
Details
Attachments
(1 file, 5 obsolete files)
(deleted),
patch
|
dougt
:
review+
|
Details | Diff | Splinter Review |
The name for the profiles dir must be easily configurable, for Mozilla to play
nicely with many Mozilla distributions.
Reasons:
- Branding
- Problem stated in bug 58326
- Profiles somethimes happen to be incompatible between versions, leading to
hangs and crashes at startup and other very wierd problems.
Right now, the name finding is littered over lots of files (of which some even
have duplicates, e.g. nsAppFileLocationProvider.cpp) and not XP.
The distributor should set the name in one place, and the platform-dependant
name is then programmatically infered from that (e.g. "Mozilla" -> "Mozilla/" on
Win32, ".mozilla" on Unix).
Yes, that would mean that the profiles dir would be renamed on Unix for Netscape
6 and on Win32 for Mozilla, but that would be IMO a good thing, for the reasons
given above.
We would also have to provide a "migration tool" for profiles from another
Mozilla distro, which would just do a simple copy.
Additional Comments:
dveditz, does Mozilla find foreign profiles, even if the (default) profiles
anmes don't match? I know that this is no problem on Unix (moz*.dat lies in
.mozilla), but I'm not sure about Windows (where I saw moz*.dat files in the
Windows folder). Would that bug be a reason to move moz*.dat into the profiles
folder on all platforms (e.g. c:\win95\Mozilla\moz*.dat)?
Reporter | ||
Comment 1•24 years ago
|
||
Bhuuhuuuu! *whine*
I changed modules/appfilelocprovider/src/nsAppFileLocationProvider.cpp, but
Mozilla silently (no error) exited/crashed at startup. I did an lxr search:
<http://lxr.mozilla.org/seamonkey/search?string=%22.mozilla%22>. See it for
yourself: we have 3 different defines for ".mozilla" plus 2 normal (hardcoded)
strings. And that's just for Unix!
*Please* clean this up, ASAP. IMO, a MUSTFIX requirement for Mozilla 1.0. It's a
hell for distributors.
cls, can I use defines from configure anywhere in the source? Then, fixing this
bug for Unix would be easy, and I could take this part.
Keywords: mozilla0.9,
mozilla1.0
How annoying. We have --enable-homedir for a reason.
Benb, you can use the defines from configure that show up in config-defs.h and
config/autoconf.mk .
Reporter | ||
Comment 4•24 years ago
|
||
> We have --enable-homedir for a reason.
heh, I completely missed that. Adding it to SUMMARY.
Summary: Make profiles dir names configurable → Make profiles dir names configurable (fix --enable-homedir)
Reporter | ||
Comment 6•24 years ago
|
||
After applying the patch, I still get
[ben source]$ grep MOZ_US config-defs.h
#define MOZ_USER_DIR "$enableval"
Reporter | ||
Comment 10•24 years ago
|
||
I think, I have it fixed for Unix. But it needs testing. I can't fix it on
Win32, since I have no cpmpiler for that platform.
This bug is a pain.
Blocks: Beonex
Comment 11•24 years ago
|
||
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
Reporter | ||
Comment 12•24 years ago
|
||
Will try to create patch blindly. Will need extensive testing by you, ccarlen,
on Win and Mac.
Assignee: ccarlen → ben.bucksch
Reporter | ||
Comment 13•24 years ago
|
||
Will attach patch for Unix.
ccarlen, please r= <http://www.bucksch.org/1/projects/mozilla/review.html>.
Reporter | ||
Updated•24 years ago
|
Whiteboard: Fixed on Unix (patch attached), mostly on BeOS, not on Win32 and Mac. Need help for the latter 2.
Reporter | ||
Comment 14•24 years ago
|
||
Reporter | ||
Comment 15•24 years ago
|
||
Oh, the patch also contains the BeOS changes. I don't remember, if I found
problems with the during my BeOS build. :-( Please review the Unix changes anyway.
Whiteboard: Fixed on Unix (patch attached), mostly on BeOS, not on Win32 and Mac. Need help for the latter 2. → Fixed on Unix (tested) and BeOS (untested), not on Win32 and Mac. Need help for the latter 2.
Comment 16•24 years ago
|
||
Ben, I like the idea but one question: How does MOZ_USER_DIR get defined on
non-Unix platforms? Also, I have bug 64501 which is about to go in and affects
this greatly. The good news is, it makes this easier. In that bug, I'm moving
the responsibility of finding the app registry dir and the app registry file
from nsDirectoryService.cpp into nsAppFileLocationProvider.cpp. This condenses a
lot of code. The code for finding the profile root dir in
nsAppFileLocationProvider is nearly identical to finding the app registry dir in
nsDirectoryService. This got condensed into a call to find the "product" dir
from which the 3 other locations are based. This is what will make what you are
doing easier - there is only one place in one file where the "product" dir is
determined.
Reporter | ||
Comment 17•24 years ago
|
||
> How does MOZ_USER_DIR get defined on non-Unix platforms?
I don't know how to do that, that is why I didn't touch the other platforms.
Reporter | ||
Comment 18•24 years ago
|
||
> Also, I have bug 64501 which is about to go in and affects this greatly.
Will you merge the changes?
Comment 19•24 years ago
|
||
> Will you merge the changes?
I'd rather not do that at this point. That patch has r= and sr=. It is only
awaiting checking of build changes. Changing that patch at this point would
invalidate the review that it already has.
With this patch, redefining MOZ_USER_DIR happens at build time. How much good
is that going to do? Is the distributor who wants to change this name expected
to build the app? Maybe on Unix, unlikely on Win, and no way on Mac. What we
need is this: put the hard-coded names of files and dirs in
nsAppFileLocationProvider into resources. That way a distributor can open the
compiled app with a resource editor, change those strings as they wish and be
done. I think that would be acceptably easy for ISPs. Using string resources
would be easy on Mac and Win - not sure about Unix.
As far as the name of the product dir being defined in multiple places - that
does need to be fixed. My patch for 64501 gets that into one place as far as
directory service is concerned. The occurance in nsRegistry.cpp, IMO, does not
need to be there. Also, once that is checked in, nsFileLocations.h/.cpp can be
CVS removed once a few refs to it in command-line test tools are stripped, so
that will get rid of some file naming clutter.
So, let's get rid of extraneous, hard-coded occurances of the product dir,
bottleneck them into one spot, and then make it possible for distributors to
customize an already compiled app using string resources.
Reporter | ||
Comment 20•24 years ago
|
||
> That patch has r= and sr=.
Sure, I meant updating the patch that is attached here.
> With this patch, redefining MOZ_USER_DIR happens at build time. How much good
> is that going to do?
It is a bold step forward, because you can set it in one place (on Unix, a
configure option exists, even).
> Is the distributor who wants to change this name expected
> to build the app?
Yes. A lot of the customization implies that you build the app.
Heck, it is even hard to change the chrome (e.g. branding) or package the app
without having a build environment. If you don't, you bascially have to rewrite
the build system.
So, somebody who wants to change the profile dir (which currently not even
Netscape does(!), so an ISP is unlikely to do it) is likely to have a completel
build environment anyway.
Sure, it would be nice to have confiurable after the build. But to be really
useful, it should be in a textfile (e.g. a .properties files). Resource editors
usually come with compilers...
What is way more important however is the time: This bug should be fixed on all
platforms for Mozilla 0.8. Sharing a profile dir between Beonex Comm. and
Netscape 6 on Windows gave Beonex Comm. users considerable headache and I am not
keen to repeat that.
Reporter | ||
Updated•24 years ago
|
Keywords: mozilla0.8
Target Milestone: mozilla0.9 → mozilla0.8
Reporter | ||
Comment 21•24 years ago
|
||
> Sure, I meant updating the patch that is attached here.
maybe, I'll do that.
Comment 22•24 years ago
|
||
> Yes. A lot of the customization implies that you build the app.
With what I'm going to check in, they can customize easily. Then, an embeddor or
somebody who wants to customize by building can supply their own implementation
of appfilelocprovider and it will be used instead of the default. With that,
they can customize any app-relative file or dir - not just the registry/profile
dir. Again, this depends on everything using directory service like it should.
That's why I think we should concentrate on removing extraneous, hard-coded
occurances of the product dir name.
> Sure, it would be nice to have confiurable after the build. But to be really
> useful, it should be in a textfile (e.g. a .properties files). Resource
> editors usually come with compilers...
Resource editors may come with compilers but not nescesarily. On Mac, it's a
small, free utility with which users change menu shortcuts and so on. It doesn't
require any knowledge of building a program.
Reporter | ||
Comment 23•24 years ago
|
||
> That's why I think we should concentrate on removing extraneous, hard-coded
> occurances of the product dir name.
What about the time? When will this be completed?
> Resource editors may come with compilers but not nescesarily. On Mac, it's a
> small, free utility with which users change menu shortcuts and so on.
I know, but on Windows, normal users don't use resource editors. On Unix, I
don't know of such a thing.
I am not opposed to it, I just doubt the usefuleness.
Reporter | ||
Comment 24•24 years ago
|
||
Nobody reviewd so far :-(, so I have to move to Mozilla 0.9. Please review!
Reporter | ||
Updated•24 years ago
|
Target Milestone: mozilla0.8 → mozilla0.9
Updated•24 years ago
|
Keywords: mozilla0.8.1
Updated•24 years ago
|
Keywords: mozilla0.8
Reporter | ||
Comment 25•24 years ago
|
||
Mass-change: Do not remove nominations (even if Milestone passed). Readding
mozilla0.8 nomination.
Keywords: mozilla0.8
Comment 26•24 years ago
|
||
I'd need to see a new patch. This code involving the product dir has changed
quite a bit since the last patch here. Two suggestions:
(1) The #defines at
http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsDirectoryService.cpp#92
should go away. They're not used. I thought I had yanked them before.
(2) http://lxr.mozilla.org/seamonkey/ident?i=EnsureDefaultRegistryDirectory
should go away. Directory service is used to find that dir on all platforms
anyway - don't see why Unix is any different.
(3) nsFileLocations.h/.cpp is not used and is going to be removed - don't worry
about it.
Given these points, the product directory should be defined in only one place.
Then, is this still an issue?
Comment 27•24 years ago
|
||
Ben: Are you able to make a new patch, as Conrad requests?
Gerv
Reporter | ||
Comment 28•24 years ago
|
||
Yes, I am. But I have objections. My comments:
(1): I'll check that.
(2), (3): Well, then remove them. *I* don't have the QA resources (especially:
diversity of installations) to test, if they are used or not. So, I will modify
that code, just to be sure. If you don't accept the change, then be it. As for
Beonex Comm., I need to be sure, that no freaky code path still uses ".mozilla".
I needed to update the patch for Beonex 0.7-dev anyway. Will attach patch as
soon as (1) is checked.
Reporter | ||
Updated•24 years ago
|
Target Milestone: mozilla0.9 → mozilla0.9.1
Reporter | ||
Updated•24 years ago
|
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Reporter | ||
Comment 29•24 years ago
|
||
Reporter | ||
Comment 30•24 years ago
|
||
Here is a new patch against Mozilla 0.9.1. It also includes a few changes for
BeOS, which should work, but are untested.
I still try to change all places where ".mozilla" appears, of which there are
still a few. See last comment for rationale.
Conrad, please review.
Reporter | ||
Comment 31•24 years ago
|
||
FYI: I have a BeOS build environment, but one build takes half a day in which my
machine is blocked, so I do this only when absolutely necessary.
Reporter | ||
Updated•24 years ago
|
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Reporter | ||
Comment 32•24 years ago
|
||
timeless gave me access to his machine, so I could fix Win32, too. Will attach
patch once I managed to transfer the stuff back to my machine. Conrad, can still
review the Unix part, it's unchanged.
Whiteboard: Fixed on Unix (tested) and BeOS (untested), not on Win32 and Mac. Need help for the latter 2. → Fixed on Unix and Win32 (tested) and BeOS (untested), not on Mac. Need help for the latter.
Reporter | ||
Comment 33•24 years ago
|
||
Reporter | ||
Comment 34•24 years ago
|
||
OK, attached the patch, which includes Win32 changes.
To change the dir under Unix, set MOZ_USER_DIR=Foldername in your build
environment. If it's not sat, it defaults to Mozilla.
As for the other platforms, the change will probably be trivial, just change the
precompiler if statement in nsAppFileLocationProvider.cpp. You will also need to
modify the build environment to add the new flag/define MOZ_USER_DIR, defaulting
to "Mozilla". I don't have access to a Mac or OS/2, so my part is done.
Reporter | ||
Comment 35•24 years ago
|
||
> To change the dir under Unix
s/Unix/Win32/
Conrad, please review.
Comment 36•24 years ago
|
||
Looks good & safe. r=ccarlen. CC'ing mkaply for his possible interest on OS/2.
I'll see if there's any interest on Mac. If so, I'll do it.
Comment 37•24 years ago
|
||
my $0.02: I would be interested in seeing a mac fix for this. I don't think it
would be too hard to do (famous last words...)
Keywords: mozilla0.8
Comment 38•24 years ago
|
||
We actually already did this on OS/2.
We created an environment variable called MOZILLA_HOME that is used for all
mozilla written files and user dirs.
Reporter | ||
Updated•24 years ago
|
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Reporter | ||
Updated•24 years ago
|
Target Milestone: mozilla0.9.4 → mozilla0.9.6
Reporter | ||
Comment 39•23 years ago
|
||
No sr for Win32/BeOS changes so far, although I asked (repeated times even,
IIRC) for it on reviewers@.
Comment 40•23 years ago
|
||
The win32 build changes look fine. The BeOS changes do not, however. You're
changing the default profile location from mozilla to .mozilla which means that
the existing install base (however small that is) will break. You may want to
announce that sort of bustage first.
The OS/2 MOZILLA_HOME shouldn't be hardcoded either. Since they use configure
as well, people will expect --enable-homedir to change it for them too. I
suggest adding a DEFAULT_MOZ_USER_DIR that defaults to .mozilla and then
override it in the platform section for BeOS & OS/2.
Reporter | ||
Comment 41•23 years ago
|
||
> The win32 build changes look fine.
Is that an sr=cls?
> You're changing the default profile location from mozilla to .mozilla
That was not intended, thanks for pointing it out.
Comment 42•23 years ago
|
||
Just to clarify, MOZILLA_HOME on OS/2 sets the location on the system where the
Mozilla directory is created. So if MOZILLA_HOME is set to D:\foo\, you get a
D:\foo\Mozilla directory.
Unlike Windows or Unix, we have no standard location to put the user
preferences. We can't default to the boot drive because it might be a FAT drive.
So we created MOZILLA_HOME so that the Mozilla directory has a place to go.
I'm assuming that this bug is to change the name of the Mozilla directory if my
product name is say Fluffy.
Chris, are you saying that on OS/2, in addition to changing the name of the
Mozilla directory to Fluffy, we should also cause --enable-homedir to change the
name of our environment variable to FLUFFY_HOME?
I think our original idea was that MOZILLA_HOME would get any Mozilla based
product directories in it, so MOZILLA_HOME would stay the same and get Mozilla
and Fluffy directories underneath it.
Comment 43•23 years ago
|
||
I'm sorry, I misread the purpose of MOZILLA_HOME.
--enable-homedir is separate from MOZILLA_HOME.
MOZILLA_HOME is what lets you change D:\foo\Mozilla to C:\Apps\Mozilla .
--enable-homedir is what lets you change D:\foo\Mozilla to D:\foo\galeon.
Maybe --enable-homedir is a misnomer? --enable-user-profiledir ?
Reporter | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.6 → mozilla0.9.8
Comment 44•23 years ago
|
||
i think i disagree w/ the BeOS change, but i'd like BeOS user comments.
Comment 45•23 years ago
|
||
First, thanks for asking the Be community for their input.
The change in the directory name to for the mozilla settings under BeOS does not
follow the "standard" way of storing setting information for BeOS applications.
Typically, settings information is stored under the
$HOME/config/settings/{app_name} directory/file.
Putting a . front of the directory name is a *nix thing, not a BeOS thing.
Reporter | ||
Comment 46•23 years ago
|
||
timeless, Arougthopher,
Please reread my comment #41:
> > You're changing the default profile location from mozilla to .mozilla
> That was not intended, thanks for pointing it out.
It was an error, a bug. There is no change for Mozilla intended (apart from
making the capitalization consistent maybe). I will remove the dot before
checking it in.
Comment 47•23 years ago
|
||
Sorry, missed that. As long as there is no dot, as you said you would fix, and
the Mozilla directory remains capitalized, and, of course, under the
$HOME/config/settings directory.
-paul
BTW - if someone else is reading this, this is for BeOS only.
Reporter | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.8 → mozilla1.1alpha
Comment 48•23 years ago
|
||
isn't this option now called --with-user-appdir and shouldn't therefore the
summary be changed?
Updated•23 years ago
|
Blocks: profile-corrupt
Reporter | ||
Comment 49•23 years ago
|
||
neither of the config options work for me - I hack into the default of configure
Comment 50•22 years ago
|
||
*** Bug 179595 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
No longer blocks: profile-corrupt
Comment 51•22 years ago
|
||
let's make this bug findable
Summary: Make profiles dir names configurable (fix --enable-homedir) → Make profiles dir names configurable (fix --enable-homedir, now called --with-user-appdir)
Comment 52•22 years ago
|
||
*** Bug 209556 has been marked as a duplicate of this bug. ***
Comment 53•22 years ago
|
||
-> xpcom
Assignee: ben.bucksch → dougt
Status: ASSIGNED → NEW
Component: Profile Manager BackEnd → XPCOM
Priority: P3 → --
QA Contact: gbush → scc
Target Milestone: mozilla1.1alpha → ---
Assignee | ||
Comment 54•22 years ago
|
||
is this third fix in a state that should be reviewed?
Comment 55•22 years ago
|
||
Not quite.
Reporter | ||
Comment 56•22 years ago
|
||
No, it's way too old. Sorry for not having cared about this bug. Unix has been
fixed in the meantime anyways, and IIRC Windows as well.
Reporter | ||
Comment 57•22 years ago
|
||
> Unix has been fixed in the meantime anyways, and IIRC Windows as well.
I retract that. I may have been running with the patch all the time. I'll check
this out when I move to 1.4 with Beonex Comm..
Comment 58•22 years ago
|
||
Pretty much the same patch updated against the trunk where everything but mac
classic uses configure.
Attachment #18244 -
Attachment is obsolete: true
Attachment #22602 -
Attachment is obsolete: true
Attachment #37805 -
Attachment is obsolete: true
Attachment #41320 -
Attachment is obsolete: true
Comment 59•22 years ago
|
||
Sets the proper default name for OSX builds.
Attachment #126654 -
Attachment is obsolete: true
Updated•22 years ago
|
Attachment #126806 -
Flags: review?(dougt)
Assignee | ||
Comment 60•22 years ago
|
||
Comment on attachment 126806 [details] [diff] [review]
v4.1
looks fine.
Attachment #126806 -
Flags: review?(dougt) → review+
Comment 61•22 years ago
|
||
Patch has been checked in.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Whiteboard: Fixed on Unix and Win32 (tested) and BeOS (untested), not on Mac. Need help for the latter.
Target Milestone: --- → mozilla1.5alpha
You need to log in
before you can comment on or make changes to this bug.
Description
•