moving location of user's home directories leaves old profiles stranded.

VERIFIED DUPLICATE of bug 157662

Status

defect
VERIFIED DUPLICATE of bug 157662
16 years ago
15 years ago

People

(Reporter: mozilla, Assigned: jag+mozilla)

Tracking

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Description

16 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529

I moved my user profile directories from C:\Doc & Set, to "C:\home".  Mozilla
ignores the value of %UserProf% as the base for the user's home directory and
can't find the datafiles (which are now under C:\home\application 
data\mozilla...).

I  realize this may be a corner case, but when Mozilla tries to come up, it
says the profile directory doesn't exist.  It could ask where it was located,
(Browse), change the path in registry.dat, and move-on from there.  I can
see the text in registry.dat pointing at C:\doc&settings..., but since it's
a binary file I'm not comfortable trying random changes.

I can temporarily recreate the user's profile under C:\doc&settings, but
then how do I move them to the corrected location?  

Under bug 77924, there is a similar problem, but as near as I can follow the
suggested workaround referenced at the end of the bug, I haven't gotten it
to work.  Under C:\home...<mozprofdir> I see "default" and "Default User".
"default" contains the correct information.  I tried copying the data under
default/<olduniqid> -> "Default User"/<newuniqid>, that didn't work.  I tried
copying the entire directory <olduniqid> to reside under "Default User". 
That didn't work.  Neither way is picking up the new location.

Under the "Profile manager", there is "rename, copy, delete"....
"it would be nice" if there was an "edit" -- to point the profile at the
new correct directory.  This certainly isn't str8 forward (but hardly anything 
is).



Reproducible: Always

Steps to Reproduce:
1. copy old home to new location
2. log into a different administrative signon to copy the user registry files 
that were in use when you did step 1 (they won't be copyable)
3. Fix registry variables in local machine to point to UserProf to <new>/%user%
then log back in as original user...most apps transparently use the new
location.  A few use hard coded values rather than relative values (including
some MS apps).  To catch 'cheating applications', rename old dir to 'olddir' so
no information is actually lost

Actual Results:  
Moz can't find profile files because old dir doesn't exist.  Only option is
to create new profile.


Expected Results:  
Should have asked if user where the files were now located or if user wanted
to create a new profile. Instead, can only create new profile.



I don't know if one should call this a feature enhancement or a bug -- is it
a bug that it doesn't use a relative value off of the user's "Home" dir?

If I was on unix/linux, does it use "$HOME", or does it store user profiles
using an absolute pathname?

I would home it is the former.  If not, I would tend to call it a bug and 
though changing home directory paths is not as common in Win(XP), it does
happen -- especially in Win98/ME when one goes from having 1 profile for 
1 person to allowing 'multiple profiles'. 

I'm guessing Moz will use the original single-user profile under the 
C:\windows\application data dir rather than updating and using the user
profiles dir.  This could provide a rude shock if the user was backing up
their user directory and expected that was saving their user-specific data,
but a later restore wouldn't restore it.  *Ick*.
Reporter

Comment 1

16 years ago
See also, related bugs 125721, 77924
Component: NSPR → Profile Manager FrontEnd
Product: NSPR → Browser
Version: other → Trunk
It would not work if Mozilla would find the profile itself because there are
absolute paths in prefs.js

dupe of bug 22689

*** This bug has been marked as a duplicate of 22689 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
I agree with bug 22689 comment 41 that this is not a dup, the dup bug would only
be a workaround or blocker for this one.

Goven the way Mozilla currently wokrs, this bug is hard to fix. Relative paths
in profiles and the Mozilla registry would probably be a blocker.

> If I was on unix/linux, does it use "$HOME", or does it store user profiles
> using an absolute pathname?

It uses absolute pathnames on Unix as well - you can't move the home dir.
However, because /home/ is predefined and you're unlikely to change your login
name, the path is relatively stable. /home/ is often a symlink on Unix systems.
Luckily, Mozilla uses /home/loginname/, not the real path.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---

Comment 4

16 years ago
Reassigned to Browser:Profile Manager FrontEnd's owner
and QA contact.
Assignee: wtc → jaggernaut
QA Contact: wtc → gbush

*** This bug has been marked as a duplicate of 157662 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → DUPLICATE

Comment 6

16 years ago
v
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.