57464 - Profile that has been renamed still keeps some old data when used as a new profile name

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Profile: BackEnd, defect, P3)

Description

[ji]

*****Observed with win32 2000101909 branch build****

After a profile is renamed , the old  profile name still keeps some old data when the user uses it as a new profile.
Steps to reproduce:
1. Create a profile, say "profileA"
2. Lauch browser using profileA. Set mail account, then exit.
3. Launch browser, rename "profileA" to "profileB", start browser, use mail, then exit.
4. Launch browser, click on Manage Profiles button, you'll see profileB is listed. 
   Create a new profile using a name of "profileA", then start browser using "profileA".
5. Lauch Mail from Task bar. Since "profileA" is a new profile, it shouldn't have any mail account set up yet.
   But actually it still uses the mail account which has been set up before renamed.

Comment 1

[(not reading, please use [e-mail] instead)]

just talked this over with racham.

the correct fix would be do this:

only use the directoy if it is not already being used for a profile.  we need to
iterate over all the profiles in the registry and check the directories.  we'd
have to compare persistent descriptor strings, since the paths could be aliases
or sym links.

Comment 2

[racham]

bug 17457 is filed to implement to get the confirmation from the user to use the 
directory if it already exists and that is something we had in 4.x. So, we need 
to put further thoughts in fixing this bug and not undoing the fix for bug 
17457.

Comment 3

[racham]

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.

Comment 4

[Conrad Carlen (not reading bugmail)]

Set milestone to mozilla0.9

Comment 5

[Conrad Carlen (not reading bugmail)]

-> 0.9.1

Comment 6

[Conrad Carlen (not reading bugmail)]

I think this will be solved by bug 17457. You will have to confirm whether to
use an existing dir when creating the new profile.

Comment 7

[Asa Dotzler [:asa]]

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)

Comment 8

[Conrad Carlen (not reading bugmail)]

Pushing off to the future.

Comment 9

[HARUNAGA Hirotoshi]

*** Bug 217196 has been marked as a duplicate of this bug. ***

Comment 10

[timeless]

*** Bug 113203 has been marked as a duplicate of this bug. ***

Comment 11

[HARUNAGA Hirotoshi]

Bug 113203 has been marked as a dup of this, so changing to All/Critical.

Comment 12

[Andreas Kunz]

*** Bug 225935 has been marked as a duplicate of this bug. ***

Comment 13

[Michael Dooley]

(In reply to comment #6)
> I think this will be solved by bug 17457. You will have to confirm whether to
> use an existing dir when creating the new profile.

While this seems to be an old issue "gathering dust" it still remains problematic in my view.

Between Bug 57464 and Bug 113203 discussions there is/was a real problem which still persists.

It is possible that after renaming a profile (not sure whether an old name is an issue here) but after renaming or attempting to "rename" a profile it is possible for a "system event" to simply result in the entire loss of an existing profile.

In my case I simply "lost" 6 weeks of data and activity in a Mozilla profile that had been created when shortly after "renaming" an existing profile a "system event" required or forced a system shutdown and reboot.

I suspect as was in my case and likely is an element of some other bug reports out there it can be traced in part in attempts to "label" bookmark files within the Bookmark Manager.

Changes are introduced - seem to retained - but are then "lost" on shutdown and restart - this because the subfolders of the bookmark file and their descriptions can be edited within Bookmark manager but the "name" and description for the file cannot be retained from changes introduced within the Bookmark manager.  Rather the name associated with the Bookmark file is that of the "profile" that creates the bookmark and no option for including or editing the description at this level exists within the Profile Manager features [not that this is the logical place for it anyway].

It clearly is a case where the left hand does not know what the right hand is doing and I suspect is one of many causes for individuals losing access to existing profiles or in my case completely losing a profile due to an unforseen system event.

As a longtime user of Mozilla and it's predecessors - I can certainly attest that system crashes and loss of data - though rare - do occur.  It is all too common to lose a bookmarks file and have no "trace" of any of the changes made over weeks or months if a manual backup has not occurred in the interim.

Someone has at least attempted to address this in Firefox with the creation of a series of bak files as part of the program and this should have been included in Mozilla or SeaMonkey long ago.

It may not be exciting or fulfilling but it is logical to:

1.  Ensure a profile can be backed up or duplicated using elements of the Mozilla/SeaMonkey program.
2.  Ensure that a bookmark file within a profile can be renamed or changed without altering the proile name.
3.  Ensure that the description for the bookmark file for a profile can be accessed and edited and changes saved over time.

Try installing SeaMonkey on a system running Mozilla.  In this system you can access a newly created SeaMonkey or the older Mozilla profile using either Mozilla or SeaMonkey as I recall {note I have had to delete SeaMonkey from this system so this comment is based on my recollection].

Try accessing the same profile using both Mozilla and SeaMonkey - can't be done as I recall.

Close both programs.  Copy the Mozilla profile in it's entirety and replace an existing SeaMonkey profile or new one created for testing with that profile and then try to use profile independently or simultaneously in SeaMonkey - GOOD LUCK!!!! What a mess!!!!

So yes programs are similar - but not the same - both can read or write to the same profile - but not at the same time - geez then how does one test???

So in my view there is a long-standing issue that has gone unaddressed:
1.  Profiles cannot be readily duplicated, exported, imported or backed up in or from within either of the existing programs.
2.  Changes to profiles or renaming profiles can create periods of non-access due to locks being embedded or to outright deletion or loss of the profile.

I suspect that that there are numerous Mozilla users (and former Mozilla users) and in the future SeaMonkey users that are going to waste time and energy because what seem to be straightforward and logical changes cannot be introduced, or if introduced are lost, and the very "act" of repeatedly attempting such changes through renaming and modifying existing profiles increases the chance of damage or loss of data.

Not venting - even if it sounds that way - but is an issue that has been long-ignored for reasons I simply cannot fathom are defendable or to justify such neglect from those capable or writing or editing such programs.


  

Comment 14

[HARUNAGA Hirotoshi]

SeaMonkey-trunk creates a new profile like as "xxxxxxxx.default".
I think this bug has been fixed.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a6pre) Gecko/2007061506 SeaMonkey/2.0a1pre

Comment 15

[baffclan]

WFM on SeaMonkey-trunk/WinXP.
I think this bug has been fixed, too.

Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.3a1pre) Gecko/20091023 SeaMonkey/2.1a1pre

Comment 16

[Marco Rios]

This bus has been duplicated, on 
Bug 113203 - Data loss with renaming profiles
In Thunderbird 3.1.9 for Linux, there still exist this problem.
Please, revisit this bug, so the following Thuderbird don't suffer.
I this BUG report is about another version of "Mozilla Messagin, please, let me know.
gratefully:
Marco

Comment 17

[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.