Closed Bug 470927 Opened 16 years ago Closed 10 years ago

When the user specifies a non-standard profile location, the Profile Manager should create the new profile _under_ it rather than _at_ that location

Categories

(Toolkit :: Startup and Profile System, defect)

defect
Not set
critical

Tracking

()

RESOLVED WONTFIX

People

(Reporter: otto.koehn, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: dataloss)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1b3pre) Gecko/20081202 SeaMonkey/2.0a2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1b3pre) Gecko/20081202 SeaMonkey/2.0a2 As mentioned in BUG 366373 for Thunderbird, profile manager is faulty, it is tricky to install profiles in not-default-location. Reproducible: Always Steps to Reproduce: 1 . When going to install a new profile, e.g. "Test", profilemanager proposes as default storage location: "Documents and settings\User-account-name\Application Data\Mozilla\SeaMonkey\Profiles\letter-number-combination.Test". So far ok. However: The option "Select Folder" opens a searchwindow and if you move to the desired location, e.g. "D:\Moz-Data\Profiles" -> ok, then you expect the profile folders and files to be installed in "D:\Moz-Data\Profiles\letter-number-combination.Test". This is NOT the case, all files and folders will be stored directly in "D:\Moz-Data\Profiles" and the profilename "Test" does not appear. You have to select option "new folder" and name it manually to get the profile stored correctly. 2. If (instad of selecting the desired location in the explorer window) you manually enter the path "D:\Moz-Data\Profiles\Test" -> "ok" -> "finish", you would expect minimum to be asked "The folder "Test" does not exist, shall it be created?" instead the location will be ignored and the profile-data will be stored on the default-location directly in "profiles", again without profilename. In all cases the profiles do function properly but it will be hard to locate them later. Actual Results: profiles will be set up unnamed and not in the location desired. Expected Results: profiles to be set up in folder identifying the profile by name.
When Profile Manager/Create Profile is invoked, following panel appears(example of MS Win XP). > Enter new profile name > (A) abcxyz ( <= specified profile name ) > > Your user settings, preferences, bookmarks and mail will be stored in: > (B) C:\Documents and Settings\<?_1_?>\Application Data\Thunderbird\Profiles\<?_2_?>.<?_3_?> > Where: > <?_1_?> : user account name of MS Win > <?_2_?> : random string > <?_3_?> : specified new profile name (abcxyz when above example) Profile path selection when "Select Folder" corresponds to (B) in above panel display(profile directory itself). It means "directory which Tb uses as profile directory", and it never means "directory under which <random_string>.<profile_name> is created", since initial of "Profile Manager". So this bug is INVALID(AFAIR, many similar reports were closed as INVALID or WONTFIX). However, I think design change is better, because many users confuse; (A) "...\User_Selected_Directory" as profile directory (Is_Realtive=0), when "Select Folder" with (B) "Default directory(...\Profiles)" under which profile directory (Is_Realtive=1) is created, when "Select Folder" is not used. I think (Case-1) is far better than (Case-2). (Case-1) "...\User_Selected_Directory\<random>.<profile_name>" is created, then user complaints that excess subdirectory is created. (Case-2) "...\User_Selected_Directory" is used as profile directory. So, when delete of profile, user complaints that whole of "...\User_Selected_Directory" is deleted, due to same confusion as this bug. (AFAIK, several reports exist for this phenomenon.) Change to Case-1 means loss of capability to point already existing profile directory. But it can easily be achieved by text editing of profiles.ini. So I think it's not big issue.
Creating the new profile _at_ the location specified by the user is the current "official" behaviour, so I'm lowering the severity to RFE, but I'm not convinced it shouldn't be WONTFIXed. When I specify a nonstandard profile location, I want the new profile to be created where I said, not somewhere else. If this RFE is accepted and "fixed" I expect a shower of "regression" bugs from people who wonder why SeaMonkey isn't anymore creating / using the profiles where they say they are.
Severity: normal → enhancement
Component: General → Startup & Profiles
OS: Windows XP → All
QA Contact: general → profile-manager
Hardware: x86 → All
Summary: Profile manager does not work properly. → When the user specifies a non-standard profile location, the Profile Manager should create the new profile _under_ it rather than _at_ that location
Version: unspecified → Trunk
(For current design/confusion) When user selected user's directory via "Choose Folder", panel is changes to following. In this case, "profile name" is independent from the directory name. > Your user settings, preferences, bookmarks and mail will be stored in: > <Path_Name_of_User_Selected_Directory> To Otto Koehn(bug opener): Message clearly says "profile is stored in here". Message never says that user selected directory is 'profile location' where profile is created. So your bug summary is wrong. (For Enhancement) If (2) in below will be added, I think it'll satisfy bug opener's requirement. (1) Current default action. <random>+<prof_name> is created under default profile location(...\Profiles) "Use Default Folder" button is already available for "back to (1) from (3)". (2) Same behaviour as (1), but different profile location. <random>+<prof_name> is created under user selected directory. "Use My Folder" button may be a simplest UI for this purpose. (3) Current "Choose Folder". User_Selected_Directory is used as profile directory.
Otto Koehn, you looks to be requesting new feature of user specified *PROFILE_LOCATION*. And, as Tony Mechelynck changed to Severity=Enhancement, your request is reasonable, although it's never mandatory feature. I think you'd better to change bug summary slightly, because normal answer to your current bug summary = INVALID.
WADA, I have managed to install my working-profile where I wanted it to be - but it took several attempts and I know, some other users who had the same difficulties. I think it would be easier, (similar but not identical to SM1.x) if after "select folder" <random>+<prof-name> would be installed in the selected folder, without necessity to enter manually <random>+<prof_name>. At present, if you do not create and give name to a new folder, the profile-folders and subfiles will be stored without profilename. I am sure, this will lead to confusion. Have you ever tried to specify the profile location by manually entering the path: <drive>:\folder\<prof_name>? it will not be accepted and profile folders and files will be stored in random location "profiles" -as correctly announced - but do users reeally re-check storage location after entering the path? I doubt it.
Some users might be tempted to go against the recommended procedure and use their Sm 1.1 or Moz profile at its old location rather than migrating it. Currently this is possible by pointing the Profile Manager to ~/.mozilla/default/aq2c9x5b.slt (or the equivalent location on non-Unix-like platforms). With your proposal, Otto, this won't be possible anymore. I don't know if this is an argument for or against this RFE.
(In reply to comment #5) To Otto Koehn(bug opener): As Tony Mechelynck says, your proposal breaks current "Choose Folder" feature(==use already existing profile directory, for ease of migration). So I presented new "Use My Folder" feature("Use my favarite Profile Locaion" may be better) in my Comment #3. That's same as you request except label of button, without breaking current "Choose Folder", isn't it?
Component: Startup & Profiles → Startup and Profile System
Product: SeaMonkey → Toolkit
QA Contact: profile-manager → startup
In replay to comment #7 looks good.
Bug 486834 is a rather interesting side effect of the current behavior.
Blocks: 486834
this would help avoid dataloss
Blocks: 302087
No longer blocks: 486834
Severity: enhancement → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: dataloss
Blocks: 366373
My thought is to have a "Create New Folder" checkbox that is checked by default, along with an explanation that this will create the new profile in a subfolder at the chosen location - and a warning about the potential dataloss consequences of unchecking it.
(In reply to comment #12) > My thought is to have a "Create New Folder" checkbox that is checked by > default, along with an explanation that this will create the new profile in a > subfolder at the chosen location I bellieve it's dangerous. > - and a warning about the potential dataloss consequences of unchecking it. I believe it's wrong UI, after generating dangerous UI... :-) I think natural enhancement of current is next; (i) Create profile(==entry in profiles.ini) with creating profile directory. [ ] Under default directory <= existent feature [ ] Under user specified directory <= requested feature by this bug If files exist in the specified directory, issue warning. (container of profile directory usualy contains profile directories only) (ii) Create profile(==entry in profiles.ini) with existent profile directory. This is existent feature. If mandatory files/directories such as prefs.js, minidumps, is not found in the specified directory, issue warning.
see also Bug 1120291
To the extent that we support the profile manager UI, we're not going to make changes to it now.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.