From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6+) Gecko/20011110 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 program". While true that it takes a weird combination of events to do this, consider the following: 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.
Conrad, 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
The rationale is explained here (thanks for good, detailed comments!) http://lxr.mozilla.org/mozilla/source/profile/src/nsProfile.cpp#1711 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 comments.
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.
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: http://lxr.mozilla.org/mozilla/source/profile/resources/content/createProfileWizard.js#165 (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.
*** Bug 61952 has been marked as a duplicate of this bug. ***
Created attachment 63905 [details] [diff] [review] don't reuse the profile in a directory. 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.
Comment on attachment 63905 [details] [diff] [review] don't reuse the profile in a directory. That's what I wanted. r=ccarlen.
bug 22689 was filed for Import Profiles
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.
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.
Per Nav Triage: nsbeta1-
*** This bug has been marked as a duplicate of 57464 ***