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)

x86
All
defect

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.
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
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: helpwanted, pp
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.
what does 4.x do?
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.
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.
reassigning to racham.
Assignee: putterman → racham
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...?
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?
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
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
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.
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.
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
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
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
verified dupe
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.