Closed
Bug 54503
Opened 24 years ago
Closed 22 years ago
fails to handle home directory path change on startup
Categories
(Core Graveyard :: Profile: BackEnd, defect, P3)
Tracking
(Not tracked)
VERIFIED
DUPLICATE
of bug 137006
mozilla1.0.1
People
(Reporter: hp, Assigned: ccarlen)
Details
(Keywords: helpwanted, platform-parity)
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; m17) Gecko/20000821
BuildID: 2000082115
If you rename your home directory for whatever reason (not that unusual in a
large network installation), mozilla gets totally confused when reading stuff
from ~/.mozilla because it had hardcoded
paths containing your old home directory. It exits silently with no error
message; there should at minimum be an error message. A simple way to address
the problem is to convert any path that matches the user's current home
directory into "~" just before saving it to disk, and then when reading in a
path expand ~ to the current home directory.
Reproducible: Always
Steps to Reproduce:
1.Run Mozilla
2.Move home directory
3.Run Mozilla
Actual Results: Mozilla exited silently
Expected Results: Error message at minimum, started up normally would be better.
Comment 1•24 years ago
|
||
not sure if this should be in backend prefs or profile management...methinks the
latter, but do change as needed.
Assignee: dveditz → putterman
Component: Preferences: Backend → Profile Manager BackEnd
QA Contact: sairuh → gbush
Comment 2•24 years ago
|
||
I guess I'm the default prefs guy, but I think a change like this would affect
more than just prefs. Also will probably require lots of #ifdef XP_UNIX coding.
CC'ing some xheads for advice.
Comment 3•24 years ago
|
||
It's not really profile manager or prefs back end, it's kind of both plus
several other places. We tend to expand paths whenever we can in lots of
places.
Comment 4•24 years ago
|
||
what does 4.x do?
Comment 5•24 years ago
|
||
I've run into this, too -- it's annoying since I can't copy my prefs from my
work to my home machine without a lot of path editing. The suggestion of using
~ sounds like a good one, but in most cases the home directory is coming from
someone using our standard file locations classes (which are already different
per-platform) -- is there any chance we could modify those classes to handle the
~ there, so the prefs don't have to have a lot of #ifdef'ed code? The problem
probably applies to more than prefs, anyway.
Comment 6•24 years ago
|
||
4.x writes out full pathnames to home directory.
I get around the home/work problem with:
ln -s /home-path/mcafee /work-path/mcafee
There are probably other scenarios that would benefit from a
tilde expansion as suggested.
Is this still happening...?
I just tried to reproduce this after changing the home to a new place.
The app came up and a profile named default is created. Let me know if this
is/isn't what you see with latest builds...?
Comment 9•24 years ago
|
||
racham's wfm doesn't address tilde expansion, I think we might
be stumbling in quite a few areas other than startup. Maybe
fork off a separate bug for that?
Comment 10•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
Assignee | ||
Comment 11•24 years ago
|
||
Similar (if not a dup) to 12911. Having relative file specs would solve this. It
would require work in more than just profile mgmt.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
Comment 12•24 years ago
|
||
We do have a resource:/ProfileDir/ or similar URL spec we could use. It
appeared to be broken last time I tried it, or perhaps I was running afoul of
some security mechanism when I tried to use it on a test .html page. Wouldn't
help us find the profile itself, but once found this could be used in various
prefs.
Assignee | ||
Comment 13•24 years ago
|
||
What I was thinking was to have something on nsILocalFile -
getRelativeDescriptor(in string fromKey, out string desc);
initFromRelativeDescriptor(in string fromKey, in string desc);
The fromKey parameter is any directory services location defined in:
http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsDirectoryServiceDefs.h
or
http://lxr.mozilla.org/seamonkey/source/modules/appfilelocprovider/public/nsAppDirectoryServiceDefs.h
The desc param is what you would save into prefs, profile registry, etc. It
would be the combination of fromKey and a relative file path - relative the the
file location which dir services returns for fromKey. We could write the path as
UTF8 with Unix path notation and the Mac and Win implementations would know how
to convert this to a native file path.
This is similar to if we had a resource:/DirServiceKey/ URL - just easier and
more efficient since it would avoid converting between an nsIFile and a URL spec.
Comment 14•23 years ago
|
||
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
Comment 15•22 years ago
|
||
The same problem exists under OS/2. It's very hard to change Mozilla home
directory location (SET MOZILLA_HOME=...) since there are a lot of direct
references (absolute paths) to its contents.
Changed OS -> All.
OS: Linux → All
Assignee | ||
Comment 16•22 years ago
|
||
The functionality for having paths which are relative and resolved at runtime
was checked in with bug 12911. It's better than simple ~ expansion - it can be
done using any location known to directory service, and it's XP. Changing
consumers which store file locations to use the new facility (of which mailnews
is the main one) is bug 137006. Making dup of that since it's the remaining work
on this problem.
*** This bug has been marked as a duplicate of 137006 ***
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Updated•9 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•