284413 - Profile folder can not be found, if the Home folder of the user has a different absolute path on different machines

Status: RESOLVED DUPLICATE of bug 157662

(SeaMonkey :: Startup & Profiles, defect)

Description

[Hannes]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 MultiZilla/1.6.4.0b
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 MultiZilla/1.6.4.0b

In Windows XP using roaming profiles, under certain circumstances it happens,
that the HOME folder of the User has a different absolute path, depending on the
Machine the user logs on. 
In this cases Mozilla cannot find the Profile of the user.

Reproducible: Always

Steps to Reproduce:
This is difficult to explain:
1. Configure Mozilla on Client A (Home Path: c:/documents and setings/thomas/)
2. Logoff
3. Login on Client B (Home Path: c:/documents and setings/thomas.MYDOMAIN/)
4. Start Mozilla

Actual Results:  
The Profile Manager opens and asks you which profile to use, because the default
Profile could not be found

Expected Results:  
Mozilla should start seamlessly on every Client, whether if the absolute path of
the profile is different on every machine.

How come that the users home folder has a different absolute path?

If user Thomas exists locally on the machine, the folder c:/documents and
setings/thomas/ already exists.
If domain user Thomas now logs on the same machine, his home folder has to be
named differently (c:/documents and setings/thomas.MYDOMAIN/) .

Comment 1

[Rob Janssen]

Although it gets better over time (both with Windows versions and Mozilla
versions) the handling of the configuration directory has been troublesome for
us all the time.
In a corporate environment we want a predictable profile location so some things
can be manipulated in logon scripts.  We want no absolute pathnames or randomly
generated names.

To make this possible in Mozilla (and before with some other apps, but as of now
all of those have been fixed by their suppliers) we do the following in the
logon script:

SUBST V: %USERPROFILE%

Then we reference all user profile information in broken apps relative to this
V: drive.
In the logoff script the SUBST has to be deleted (/D) again.

Hopefully this is useful for you as a workaround.
But it would be really nice if this problem is fixed in Mozilla as well.

Comment 2

[OstGote!]

*** This bug has been marked as a duplicate of 157662 ***