Closed Bug 20198 Opened 25 years ago Closed 25 years ago

[DOGFOOD]Deleting Profiles Deletes ALL profiles

Categories

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

x86
Windows 95
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: bugs, Assigned: racham)

Details

(Whiteboard: [PDT+])

I have discovered (the hard way) what appears to be a bug that can have (as I
have experienced) tragic circumstances.

What happened:
I was making some fixes to the Profile Wizard, and after successfully creating a
few profiles, I went to the Profile Manager to delete them. I selected and
deleted each profile individually using the GUI. The tree in the profile manager
then consisted of my 4.x profiles (with "Migrate" next to them) and my main
mozilla profile, "fooProfile".

I then noticed that the copy of Communicator 4.7 running concurrently wouldn't
download my mail, so I restarted. When I started Communicator 4.7 again using my
standard profile, I noticed I still couldn't check my mail. I looked in my
Netscape users folder (on a different drive to my Mozilla users folder) and
noted all the folders for 4.x profiles were gone. It appears Mozilla has not
only deleted my Mozilla profiles, but somewhere along the way my 4.x profiles as
well. I noticed quite a bit of disk activity during one of the deletions. This
would suggest something seriously wrong with the list of profiles-to-be-deleted
passed through the ProfileManager's interface.

What Should happen:
If I don't select a profile to be deleted, it shouldn't be deleted!
Also, if files exist in the folder that were not created by Communicator (e.g.
in my case, zipfiles that I created of old mail) should either have "are you
sure you want to delete this", not be deleted, or some sort of warning be put in
place.
This bug is another example of why 18927 should be fixed, although fortunately,
it looks like I'm preaching to the choir at this point. ;)
Assignee: selmer → racham
Priority: P3 → P1
Target Milestone: M12
Bhuvan, this looks critical for M12.
Status: NEW → ASSIGNED
When a unmigrated profile is to be deleted only the registry entry should be
deleted. Not the 4.x folder. Need to add logic in profile.cpp's deleteProfile
routine or profileManager.js's deleteProfile to check the migrate status before
accepting the recursive delete flag to delete the entire folder. If the profile
is unmigarted the flag should be set to FALSE to avoid the side-effects.
Accepting the bug.
Summary: Deleting Profiles Deletes ALL profiles → [DOGFOOD]Deleting Profiles Deletes ALL profiles
Whiteboard: [PDT+]
4.x profiles should not be touched. Please fix ASAP.  Putting on PDT+ radar.
One thing I noticed with today's commercial build is that one can't delete
a profile that has "Migrate" next to it. You should get a dialog that says
migrate the profile before doing delete activities. So, we should not be able
to delete unmigrated profiles.

rgoodger@ihug.co.nz,

Did you make any changes to the js script that checks the migrate flag before
before deleting the profile ? Haven't you seen this dialog ?
Can you give us the exact steps to reproduce this ?

Grace,
We should try to reproduce this.
Bhuvan,

Is this the mozilla build?  In the Netscape builds, I get a dialog telling me to
migrate before I delete, also get option to NOT delete files and the only files
that get deleted are the 5.0 migrated files if I so choose.

I will try with mozilla builds next.
using build from 11/26 - mozilla- not able to reproduce, I always get dialog to
migrate before deletion, once I do that and choose delete, only the 5.0 profile
files are deleted - IF I choose to delete.
Hmm, on WinNT M11 build, try this:

*WARNING*
this will delete all the files on your desktop. BACK THEM UP FIRST!
(if there are no files on your desktop create a few .txt files for fun).
1) mozilla -installer
2) Create a new profile and click on Change Folder...
3) Select your desktop
4) Hit finish.
5) Close mozilla
6) mozilla -installer
7) Select the new profile (pointing at your desktop)
8) Click delete.
9) Confirm by saying delete...

oh god! you just deleted all the files on your desktop, whether they were
mozilla's or not!
caveat: some files of mine weren't deleted... but clearly many shortcuts and
.txt files are now gone. doh!

Lot's of directories were deleted also, so I have a feeling that mozilla deleted
this poor guys directories because he assigned his preferences to the same
parent tree that Netscape 4.x stores it's preferences in.
jelwell, thanks for the great steps-to-reproduce!

I was hesitant to try it again to produce such a list ;)
When the user suppiles a native path we are just taking it directly.
We have to append the profile name to it so that the parent directory
is not affected in the deletion process. Checking the fix soon.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
just checked this in.  patch by racham, r=sspitzer

Index: src/nsProfile.cpp
===================================================================
RCS file: /cvsroot/mozilla/profile/src/nsProfile.cpp,v
retrieving revision 1.95
diff -r1.95 nsProfile.cpp
1060a1061,1067
>
>       // this prevents people from choosing there profile directory
>       // or another directory, and remove it when they delete the profile
>       //
>       // append profile name
>         dirSpec += profileName;
>         dirSpec.MakeUnique();
Status: RESOLVED → VERIFIED
using build 1999120608- extra folder prevents deletion of all files
Component: Profile Manager → Profile Manager BackEnd
Moving all Profile Manager bugs to new Profile Manager Backend component.
Profile Manager component to be deleted.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.