58327 - Make profiles dir names configurable (fix --enable-homedir, now called --with-user-appdir)

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Ben Bucksch (:BenB)]

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)?

Comment 1

[Ben Bucksch (:BenB)]

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.

Comment 2

[Ben Bucksch (:BenB)]

Filed bug 58378 about the 2 copies of appfilelocprovider

Comment 3

[cls]

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 .

Comment 4

[Ben Bucksch (:BenB)]

> We have --enable-homedir for a reason.

heh, I completely missed that. Adding it to SUMMARY.

Comment 5

[cls]

Attachment: MakeFix --enable-homedir to evaluate the variable instead of quoting it

Comment 6

[Ben Bucksch (:BenB)]

After applying the patch, I still get

[ben source]$ grep MOZ_US config-defs.h
#define MOZ_USER_DIR "$enableval"

Comment 7

[cls]

Run autoconf after applying any configure.in patches.

Comment 8

[scottputterman]

reassigning to racham.

Comment 9

[cls]

The configure.in patch has been checked in.

Comment 10

[Ben Bucksch (:BenB)]

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.

Comment 11

[racham]

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.

Comment 12

[Ben Bucksch (:BenB)]

Will try to create patch blindly. Will need extensive testing by you, ccarlen,
on Win and Mac.

Comment 13

[Ben Bucksch (:BenB)]

Will attach patch for Unix.

ccarlen, please r= <http://www.bucksch.org/1/projects/mozilla/review.html>.

Comment 14

[Ben Bucksch (:BenB)]

Attachment: Fix, Unix, version 1

Comment 15

[Ben Bucksch (:BenB)]

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.

Comment 16

[Conrad Carlen (not reading bugmail)]

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.

Comment 17

[Ben Bucksch (:BenB)]

> 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.

Comment 18

[Ben Bucksch (:BenB)]

> Also, I have bug 64501 which is about to go in and affects this greatly.

Will you merge the changes?

Comment 19

[Conrad Carlen (not reading bugmail)]

> 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.

Comment 20

[Ben Bucksch (:BenB)]

> 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.

Comment 21

[Ben Bucksch (:BenB)]

> Sure, I meant updating the patch that is attached here.

maybe, I'll do that.

Comment 22

[Conrad Carlen (not reading bugmail)]

> 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.

Comment 23

[Ben Bucksch (:BenB)]

> 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.

Comment 24

[Ben Bucksch (:BenB)]

Nobody reviewd so far :-(, so I have to move to Mozilla 0.9. Please review!

Comment 25

[Ben Bucksch (:BenB)]

Mass-change: Do not remove nominations (even if Milestone passed). Readding
mozilla0.8 nomination.

Comment 26

[Conrad Carlen (not reading bugmail)]

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

[Gervase Markham [:gerv]]

Ben: Are you able to make a new patch, as Conrad requests?

Gerv

Comment 28

[Ben Bucksch (:BenB)]

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.

Comment 29

[Ben Bucksch (:BenB)]

Attachment: Fix, Unix, version 2

Comment 30

[Ben Bucksch (:BenB)]

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.

Comment 31

[Ben Bucksch (:BenB)]

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.

Comment 32

[Ben Bucksch (:BenB)]

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.

Comment 33

[Ben Bucksch (:BenB)]

Attachment: Fix, version 3. Unix, Win32 (tested) and BeOS (untested).

Comment 34

[Ben Bucksch (:BenB)]

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.

Comment 35

[Ben Bucksch (:BenB)]

> To change the dir under Unix

s/Unix/Win32/

Conrad, please review.

Comment 36

[Conrad Carlen (not reading bugmail)]

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

[Zach Lipton [:zach]]

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...)

Comment 38

[Mike Kaply [:mkaply]]

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.

Comment 39

[Ben Bucksch (:BenB)]

No sr for Win32/BeOS changes so far, although I asked (repeated times even,
IIRC) for it on reviewers@.

Comment 40

[hacker formerly known as [e-mail]]

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.

Comment 41

[Ben Bucksch (:BenB)]

> 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

[Mike Kaply [:mkaply]]

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

[hacker formerly known as [e-mail]]

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 ?

Comment 44

[timeless]

i think i disagree w/ the BeOS change, but i'd like BeOS user comments.

Comment 45

[Paul]

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.

Comment 46

[Ben Bucksch (:BenB)]

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

[Paul]

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.

Comment 48

[Christian :Biesinger (don't email me, ping me on IRC)]

isn't this option now called --with-user-appdir and shouldn't therefore the
summary be changed?

Comment 49

[Ben Bucksch (:BenB)]

neither of the config options work for me - I hack into the default of configure

Comment 50

[Ferdinand]

*** Bug 179595 has been marked as a duplicate of this bug. ***

Comment 51

[Christian :Biesinger (don't email me, ping me on IRC)]

let's make this bug findable

Comment 52

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 209556 has been marked as a duplicate of this bug. ***

Comment 53

[hacker formerly known as [e-mail]]

-> xpcom

Comment 54

[Doug Turner (:dougt)]

is this third fix in a state that should be reviewed?

Comment 55

[hacker formerly known as [e-mail]]

Not quite.

Comment 56

[Ben Bucksch (:BenB)]

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.

Comment 57

[Ben Bucksch (:BenB)]

> 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

[hacker formerly known as [e-mail]]

Attachment: v4.0

Pretty much the same patch updated against the trunk where everything but mac
classic uses configure.

Comment 59

[hacker formerly known as [e-mail]]

Attachment: v4.1

Sets the proper default name for OSX builds.

Comment 60

[Doug Turner (:dougt)]

Comment on attachment 126806 [details] [diff] [review]
v4.1

looks fine.

Comment 61

[hacker formerly known as [e-mail]]

Patch has been checked in.