Closed Bug 113203 Opened 19 years ago Closed 17 years ago

Data loss with renaming profiles


(SeaMonkey :: Startup & Profiles, defect, P2)



(Not tracked)



(Reporter: demon-lag, Assigned: bugs)



(Keywords: dataloss)


(1 file)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6+)
BuildID:    20011121xx+

I had a problem where the sidebar got "stuck" open.  Clicking on it froze the
entire UI (though not the page).  To rectify this, I renamed my profile from:
"DeMoN LaG" to "DeMoN LaG Backup".  I created a new profile (to test if this was
a problem with my profile, or a problem with Moz itself).  I named it "DeMoN
LaG".  I didn't bother to check what the location for the profile was.  Mozilla
said nothing, but put the second profile in the first profiles folder.  I
launched with that profile.  Seeing the sidebar still stuck, and not knowing it
was using the same folder for both profiles (and thus the problem with my
profile was still there), I went back to profile manager and deleted DeMoN LaG,
said yes to delete files.  I renamed the old profile back to DeMoN LaG and
attempted to launch, Couldn't.  Entire folder was gone.  All my bookmarks (well,
i have backups), cache, if I used Moz for mail and news it would all be gone
too.  This is, IMHO, a serious issue as it involves potential massive data loss

Reproducible: Always
Steps to Reproduce:
1. Create a profile called "A", use default location
2. Rename that profile to "Ab"
3. Create a new profile called "A", default location
4. Delete "A", delete files
5. Rename "Ab" back to "A", and try to launch

Actual Results:  My entire profile folder was deleted

Expected Results:  When renaming a profile, Mozilla should either rename the
folder that is storing the profile, or if a new profile is being made Mozilla
should see "Hey, there's already a profile here" and ask "Existing profile found
in %location%!  Overwrite it?" or similar.  

Right now Mozilla is a beta program, and as such data loss should be planned
for.  If this isn't fixed by 1.0 though (and I haven't checked but I assume
Netscape 6.0, 6.1 and 6.2 all have this bug), there is large amounts of
potential data loss, and I don't think Netscape or any other distributors can
tell their customers "You should back up your data often, it's not a reliable
While true that it takes a weird combination of events to do this, consider the
Someone clicks through a ton of things taking default options (ie, Default User
for profile).  They find out they can rename things later, and there are a few
people with profiles.  Someone changes their profile from Default User to Bob. 
Next time someone creates a profile, if they pick Default User, right off the
bat you have two profiles sharing a folder and overwriting each other.  And if
one of them deletes their profile, the other one is up the river without a paddle.  

It appears that Mozilla does not check if \profiles\%profile folder% exists, it
just takes the profile name and assumes it's a kosher place to put files.  Along
with the check to make sure you don't have two profiles with the same name, a
second check should be made to make sure that the current folder doesn't exist.  

This looks like it's related slightly to bug 95331, but that appears more about
"losing" the data in the sense it's there, but Mozilla can't find it.  This one
causes all the files in the \profile_name folder to be completely deleted.
fyi, check with Bhuvan on the rationale for not renaming the folder- originally 
it did work that way, but when Activation came on the scene, this 'feature' was 
introduced- rename changes name in profile list but not the directory itself.  
He may be able to tell you why that was done
Ever confirmed: true
The rationale is explained here (thanks for good, detailed comments!)
I agree that it's easy to get into trouble since people will assume that the
name of the profile folder should match the name of the profile. I'll have to
think how it could be improved with creating the scenario explained in those
I can see the rationale for not renaming the folders.  I actually agree with it.
 I just don't think the current behavior of letting a new profile create itself
right on top of an existing one is a good idea either.  I think there should be
two choices for a user to pick from if this happens:

A) Delete existing profile information (deletes the folder entirely and
recreates a new one)

B) Pick a new directory to store the profile in.  

I don't think that the folder name must match the profile name at all.  I just
don't think Mozilla should let me overwrite a current profile with a new one
without even prompting me that I'm doing it.  A simple check that the folder
doesn't exist should be fine.  If it does, warn the user that they will be
overwriting data if they create the folder there.  If they say yes, delete the
existing stuff.  If they say no, let them enter a new location for the profile.  
When creating a new proifle dir, the proifle mgr ensures the name of the profile
is unique by appending -1, -2, etc.

From your example:
2. Rename that profile to "Ab"
3. Create a new profile called "A", default location

After step 3, the profiles dir should have contained "A" and "A-1" If that's not
the case (sounds like it's not), something's broken.
Target Milestone: --- → mozilla0.9.8
Then yes, something is broken.  Mozilla appends -1, etc to the *name* of the
profile.  I just tested this again, using the steps I outlined.  I made A.  Then
I added a bookmark to it.  I renamed A to Ab.  I made a new profile named A and
didn't adjust the location (though I saw clearly it said \profiles\a).  I opened
the new A up.  It had the bookmark I added in the previous profile.  I deleted
Ab this time, deleted files.  Tried to start with A and I could not, the folder
had been deleted.  

The steps I outlined to recreate this take about 30 seconds to do, give it a try
when you get chance.  I don't have access to any other OSs at this time (two Win
2k machines here), so I don't know if this affect Linux, Mac, or any other
platforms (but I would have to assume it does)
> After step 3, the profiles dir should have contained "A" and "A-1" If that's
> not the case (sounds like it's not), something's broken.

Well, it's not the case and, looking at bug 17457, that's intentional.

We should either:
(1) Not be able to create a profile which uses some existing folder. Bug 17457
makes a case for why that's needed. I don't agree. Reclaiming an existing
profile dir should not be a hidden feature of profile creation, it should be an
explict action - called "Restore" or "Import". When creating a profile and a
directory of that name already exists, the front-end should just pass FALSE to
the back-end for the "useExisting" param to createNewProfileWithLocales() if
another profile uses that directory. Here:

(2) Since, without that, it is possible for two profiles to share the same dir,
warn the user on deleting a profile and its files, that they are deleting files
which belong to another profile.

I favor option #1. We shouldn't bother people with alerts they're not going to
read anyway when we can avoid the situation in the first place. Problem is, that
would fix the problem for the future but, as of now, there are profiles created
which share the same dir. Since that situation  is so obscure, I still favor
option #1.

In any case, it's a front-end bug. Reassigning.
Assignee: ccarlen → ben
Component: Profile Manager BackEnd → Profile Manager FrontEnd
*** Bug 61952 has been marked as a duplicate of this bug. ***
remove the 'silent import' feature that's causing this bug.

a feature request should be filed for an 'import' feature which is more obvious
and useful.
Priority: -- → P2
Comment on attachment 63905 [details] [diff] [review]
don't reuse the profile in a directory. 

That's what I wanted. r=ccarlen.
Attachment #63905 - Flags: review+
Target Milestone: mozilla0.9.8 → mozilla0.9.9
bug 22689 was filed for Import Profiles
Target Milestone: mozilla0.9.9 → mozilla1.1
Depends on: 57464
After messing up my profiles too i'm adding myself. Also moving to 1.2a seeing 
as 1.1a has past. 

bug 17457 is another for imports btw. 

OS: Windows 2000 → All
Hardware: PC → All
Target Milestone: mozilla1.1alpha → mozilla1.2alpha
Setting the blocking 1.4 flag for this bug. This bug had a patch a long time ago
(which may have rotted, but is likely to be easy to update) and causes serious
dataloss without warning. It should be prevented.
Flags: blocking1.4a?
Flags: blocking1.4a? → blocking1.4a-
Flags: blocking1.4b?
Keywords: nsbeta1
Keywords: dataloss
Per Nav Triage: nsbeta1-
Keywords: nsbeta1nsbeta1-
Flags: blocking1.4b? → blocking1.4b-
To "Assigned To:" person

Isn't it a DUPE of bug 57464 ?
If so, I think "Future" of bug 57464 is not appropriate for problem causes "Data

*** This bug has been marked as a duplicate of 57464 ***
No longer blocks: profile-corrupt
Closed: 17 years ago
No longer depends on: 57464
Resolution: --- → DUPLICATE
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.