Closed
Bug 9120
Opened 25 years ago
Closed 25 years ago
mozilla segfaults when run in a non-writable directory
Categories
(Core Graveyard :: Tracking, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
M14
People
(Reporter: renec, Assigned: scc-obsolete)
References
Details
Mozilla will not run unless you run it in a directory you have write permissions
to, instead of doing something intelligent like writing its preferences in your
~home directory.
I imagine this stops -most- people from getting it to run, I only managed to
figure out what the hell was going on by getting **** off after 30 mins and
running it as root, then wondering why it worked in that case.
It shoudl probably open all files it needs to in ~/.mozilla/ .
Updated•25 years ago
|
Assignee: chofmann → selmer
Comment 1•25 years ago
|
||
I think selmer is working on add this feature, or finding
all the areas that will need to change to make it work.
Updated•25 years ago
|
Assignee: selmer → dp
Comment 2•25 years ago
|
||
This problem is probably related to the creation of the component registry or
the profile registry global files. We need a place to store application global
data and it must be writable. For the component registry, this should only be
required on the first execution of the app. For the profile registry, you would
need to be root every time you create a profile (until we make the profile
registry live in the user's home directory.)
I think dp already has a bug like this, but I'm forwarding it to him in case he
doesn't.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M11
Updating QA Contact.
Per an email from renec:
"Why would you want the program to change ANYTHING global upon a user/new
user running the program? (see 'profile'). Profiles are sort of handled
automatically by home directories/seperate logins.
Its bad policy to alter anything out of a users home directory for
any reason.. Stuff everything in ~/.mozilla/, and all the problems go
away."
Updated•25 years ago
|
Target Milestone: M11 → M12
Updated•25 years ago
|
Priority: P3 → P1
Updated•25 years ago
|
Target Milestone: M12 → M14
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 8•25 years ago
|
||
Added <dveditz@netscape.com> at his request.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 9•25 years ago
|
||
After investigation with <dveditz@netscape.com> this is what we know:
- It's OK to run out of a read-only directory (on every platform) as long
as your component registry already exists
- It is currently the case that if the directory is read-only, and the
component registry does not exist, we can't run
- We expect in situations where Mozilla has been installed in a context that
some users will find to be read-only, that a pre-fab component registry
will have been installed as well
- <dveditz@netscape.com> says that he may have a reasonable fix the read-only
directory + no registry problem, some time in the near future --- if we
consider that to be an important case. ...essentially building the registry
in memory, but failing to write it out. This would return us to the `slow
startup' problem that pre-generated registries were to dig us out of.
<dveditz@netscape.com> says that _this_ bug is essentially fixed; and I should
close it. If we require another bug for the no-registry case, one can be
created.
Dan, is this an accurate summary?
Assignee | ||
Comment 10•25 years ago
|
||
Note: bug #20777 seems to cover the no-registry case exactly; so we don't even
need to file a new bug.
Comment 11•25 years ago
|
||
renec, does this look good to you now?
Reporter | ||
Comment 12•25 years ago
|
||
I'm confused as to why a 'component registry' has to be dynamically
generated/saved just to run the program and why it isn't part of an install
process if its something that has to be created by root, and kept in a
non-writable directory.
Most of my confusion is that I don't know what a component registry is - if its
something particular to a specific instance of the program, it should be in the
user's home directory, if not it should be part of the install process and not
touched after that...?
Thats about all I have to say about that. Mozilla should probably specifically
avoid writing in any directory that isn't ~/ or below, even if it does have
write permissions to do so...
Comment 13•25 years ago
|
||
The component registry will be installed in the future, but for developer
convenience (a component could have been rebuilt at any time) is being checked
and potentially updated each run.
I have fixes in my tree that turn off this "auto-reg" feature, people will have
to rely on the install process or explicitly run the registration utility
(regxpcom) with appropriate permission.
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
•