433205 - Renaming a Profile Fails to Rename the Folder Containing the Profile

Status: RESOLVED WONTFIX

(Toolkit :: Startup and Profile System, defect)

Description

[David E. Ross]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9

I renamed one of my four profiles.  When I go to use that profile, Profile Manager shows the new name.  It works okay.  

When I examined the storage of profiles, however, I noticed that the folder still had the old name.  I can't merely change the name of the folder without breaking Profile Manager.  

Reproducible: Always

Steps to Reproduce:
1.  Use Profile Manager to create a profile named Working1.  
2.  Use Profile Manager to change the name of the profile to NotWorking2.  
3.  Use Profile Manager to select the profile.  
4.  Use Windows Explorer to locate the profile.  
Actual Results:  
Steps 1-3 work okay.  Step 4 shows that the profile files are located in folder xxxxxxxx.slt under folder Working1.  

Expected Results:  
Step 4 should show that the profile files are located in folder xxxxxxxx.slt under folder NotWorking2.  

I changed the name of the profile because the old name too strongly suggested the purpose, which is sensitive.  I wanted a non-suggestive, generic name.  While the profile itself now has that generic name, a hostile attach on my PC is more likely to look at directory (folder) names than at the contents of registry.dat (which contains the correlation between profiles and their directories).

Comment 1

[Philip Chee]

On branch this is a WONTFIX since registry.dat is an abandoned format that nobody has worked on for ages. On trunk, SeaMonkey is using profiles.ini which is a plain text file that can be edited by any text editor. You will also need to edit your prefs.js file for any absolute paths found. This is most likely in mail and news prefs.

In addition since I believe that this is "working as designed", this bug as currently described is INVALID.

Comment 2

[David E. Ross]

The reference to registry.dat was written in the bug report section "Additional Information", not in the section "Details".  Thus, the reference itself should not be taken as justification for rejecting this bug report.  

In the 30+ years of my career as a software test engineer, we occasionally found flaws in approved design that resulted in bug reports.  In those cases, "working as designed" was simply not an acceptable response.  Instead, we required the design to be changed to something workable.  

Comment 3

[Philip Chee]

As far as I know the only consumer for the old XPFE registry.dat file is SeaMonkey 1.1.x. That branch will only get security and stability updates so registry.dat won't be fixed.

You might have slightly better luck with profiles.ini on trunk (i.e. SeaMonkey 2.0a).

Comment 4

[WADA:World Anti-bad-Duping Agency]

Following is profile.ini content of Seamonkey Trunk(same as Tb 2/Fx 2 or newer), and all of them works well as designed.
> [Profile0]
>  Name=Nightly-Test-X
>  IsRelative=1
>  Path=Profiles/6n7y4y22.Nightly-Test
> [Profile1]
>  Name=Absolute-Path
>  IsRelative=0
>  Path=C:\wada\TEST\Moz-Prof
> [Profile2]
>  Name=Different-Path
>  IsRelative=1
>  Path=Profiles-X/abc.def.pqr.xyz

[Profile0] : Initially created as Nightly-Test, at default location,
             and renamed to Nightly-Test-X via Profile Manager
[Profile1] : Created as Absolute-Path, with user specified profile location
             of C:\wada\TEST\Moz-Prof (on MS Win-XP SP2)
[Profile2] : Created as Different-Path, by editing profile.ini,
             by manual creation of Profile-X\abc.def.pqr.xyz
             (Following set of file/directory is used on MS Win      )
             ( %APPDATA%\Mozilla\Seamonkey\profile.ini               )
             ( %APPDATA%\Mozilla\Seamonkey\Profile-X                 )
             ( %APPDATA%\Mozilla\Seamonkey\Profile-X\abc.def.pqr.xyz )

Although profile manager puts string for "profile name" in directory name when profile creation at default location([Profile0]), there is no relation between profile name and profile path, as seen in above [Profile1] and [Profile2].
This is design.

I think that "offering of profile path rename when profile name change" is kind for average users especially when [Profile0] case, but I don't think it's mandatory feature.

Comment 5

[Wayne Mery (:wsmwk)]

it sounds then like this is invalid or wontfix?

Comment 6

[David E. Ross]

I now have SeaMonkey 2.0.  I did a search of both hard drives and cannot find a file named profile.ini.

Comment 7

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #6)
> I did a search of both hard drives and cannot find a file named profile.ini.

Oh, sorry for my mis-type. Search for profiles.ini instead of profile.ini, please. (I forgot that Tb's "Release Notes" never refers to profile related directory-name/file-name/parameter/operation etc., because I'm a SeaMonkey lover.)

Comment 8

[Wayne Mery (:wsmwk)]

(In reply to WADA from comment #4)
> I think that "offering of profile path rename when profile name change" is
> kind for average users especially when [Profile0] case, but I don't think
> it's mandatory feature.

right - it doesn't actually keep anything from working. (I rather agree it's working as designed)

Comment 9

[David E. Ross]

Having moved my profiles to a special directory, I now see that renaming the folder containing a profile would also require scanning pref.js to adjust any file paths in preference variable data that included the old folder-name.  Other files might also be affected.  This could be a horrendous effort to program correctly.  

As the originator of this bug report, I would accept a WontFix PROVIDING users are warned when renaming a profile that the related profile folder is not renamed.  This is required to prevent users from making a false assumption about what happens when renaming profiles.

Comment 10

[Benjamin Smedberg]

This bug is filed in a bugzilla component related to pre-Firefox code which no longer exists. I believe it is no longer relevant and I am therefore closing it INCOMPLETE.

If you believe that this bug is still valid and needs to be fixed, please reopen it and move it to the Toolkit:Startup and Profile System product/component.

Comment 11

[David E. Ross]

This can actually be a security issue.  

Profiles are usually stored in directories or folders with randomly generated names.  This is intended to obscure the locations of profiles and make them harder for hackers to find them.  

If nevertheless I see that a hacker has accessed a profile of mine, I would of course want to rename that profile to prevent further hacking.  However, renaming it would not suffice if the folder itself retained its own name.

Comment 12

[David E. Ross]

Oops!  The last sentence of comment #11 should be:

"However, renaming it would not suffice if the folder itself retained its old name."  

"own" > "old"

Comment 13

[Benjamin Smedberg]

I would not take a patch for this. You can still do this manually by editing profiles.ini, but this is the sort of complexity that is not worth solving in-product.