Open Bug 302087 Opened 19 years ago Updated 1 month ago

Inadequate warning before Profile Manager deletes non-Mozilla files

Categories

(Toolkit :: Startup and Profile System, defect)

Product:
Toolkit
Component:
Startup and Profile System
Type:
defect

Tracking

()

People

(Reporter: VanillaMozilla, Unassigned)

References

Details

(Keywords: dataloss, uiwanted, Whiteboard: See comments 60 and 66 for current status)

Attachments

(1 file, 4 obsolete files)

screenshot #2
26.97 KB, image/png
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+

By design, Profile Manager allows creating a profile in a preexisting directory
that may contain user data.  When deleting the profile, Profile Manager can
delete the entire directory and its entire contents.  In some instances users
could delete all their user data, or even the entire hard drive.

Profile Manager gives a warning that may seem adequate to advanced users, but in
practice, users sometimes suffer severe losses.  Here are the words of one user:
 "It really didnt' give me any warning. It asked if I wanted to delete the
profile and I said I did. Then everything was erased after that. There was
nothing else I did that could have erased all of my files."  Here's the report
from the Support Forum: 
http://forums.mozillazine.org/viewtopic.php?p=1624166#1624166 .

This bug depends on bug 270705 , which will not be fixed.  It has been judged to
be a feature, not a bug, but it continues to catch users, with sometimes
devastating consequences.  Would it be asking too much to fix it?

Reproducible: Always

Steps to Reproduce:
1.Create a new directory and put some expendable files in it.
2.Run Profile Manager and press <Browse> to create a new profile in that directory.
3.Delete that profile.  Select delete all files.

Actual Results:  
1. Dialog box "Delete Profile" is displayed.  Box contains the warning "This
option will delete the folder [folder path\name] and cannot be undone."  The
warning starts in the middle of line 3 of 4 or more lines, and is easily overlooked.
2. On pressing <OK> directory and all files in it (including non-Mozilla files)
will be deleted.  If placed in the root directory, I believe it would delete all
files and directories to which user has ReadWrite access.

Expected Results:  
1. Firefox should delete only the profile data, and never non-Firefox user data.

2. Even if it does, considering the possible consequences, if the directory may
have been user-created, Fx should display a very prominent warning, namely:

a. Warning should begin on a separate line.
b. Warning should be bold.
c. There should be a separate, prominent sentence.  Suggested wording: 
"Warning:  pressing <OK> may cause loss of all or part of your user files."
Depends on: 270705
It is interesting that it seems the problem has quite a large scale, but 
people 'suffer quietly'. I just had a look at bug 270705 and there have no 
been further comments. At least now (Deer Park) there is no Profile Manager in 
the Start menu, though people are instructed how to invoke it. One of the 
explanations was that the general reason to make Firefox just dump its files 
whenever it is told (without creating a specific folder) are the corporate 
system administrators who want to tell Firefox where to put its files. But why 
then it is not done FOR THEM some hacky way, and for the NORMAL people - just 
Firefox to create a folder with the name of the profile and dump its files 
inside. And when it deletes a profile, simply to delete this folder.

Why should so many people suffer (and it is obvious that they suffer) because 
big IT guys in a big companies can put more pressure on the Firefox team than 
the "small" people who just quietly suffer.

I don't really see the point.
Correction:  The user on the support forum DID lose all his computer files.

Also, I'm not sure whether I should have marked this as depending on an invalid
bug.  I believe this one is valid, even if the one it depends on is not.
The profile manager is not meant for normal people, or even advanced normal
people... only for developers who know what they're doing. If you want to
provide a patch which will make the warning scarier, you are welcome to reopen
the bug, otherwise we will leave this beast to rest.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
It would be good if the Mozilla developers get to some level of common agreement
before they start to spread their opinions and mark bugs as INVALID or WONTFIX
with some bizarre statements.

What about that -

http://www.mozilla.org/support/firefox/profile

I don't see anywhere the phrase "only for developers who know what they're doing".

I am actually quite disappointed with Firefox and the whole Mozilla thing.
People should humble themselves a little bit and push things into the pipeline,
even if this is ahead in future, instead of pretending they do not exist.

For the past some time I can't recall one ACTUAL problem with IE. But I have
quite a few with the great Firefox.
Unfortunately, profiles are in common use for debugging extensions, both by
seasoned users and by computer newbies.  Profile use is advocated all over the
Support Forum, and Fx itself even pops up the Profile Manager occasionally.

I'll work on fixes and reopen this in a couple of weeks.

Someone pointed out here:
http://forums.mozillazine.org/viewtopic.php?p=1630486#1630486 that the warning
should occur when the directory is created.  User should be warned that the
directory should be empty, and that the directory and all files in it may be
deleted without warning.

It is crucial at that point that users do not accidentally create the directory
and then attempt to rectify the error by deleting the profile.  Dumb mistakes
shouldn't result in disaster.
Reopening and attaching dataloss keyword.  This is a nasty bug.  See also bug
278230.
Status: RESOLVED → UNCONFIRMED
Keywords: dataloss
Resolution: WONTFIX → ---
This is not just a nasty bug. I just deleted valuable data, and that means
several hundred dollars. The profile deletion functionality must!!! be disabled
until the bug is fixed.
And yes, i am an experienced user. I created a new profile in a subdirectory and
expected Firefox to behave like Mozilla, which creates a new cryptic
subdirectory in it. That was not the case, so the profile resided within my
project data. So i deleted the profile to get rid of any sustaining entries in
configuration files. All my data in the project file are in Nirvana (instead of
going at least into the windows trash). Firefox must not touch any files that do
not belong to it!
And where was the warning? I can't remember any.
I will now delete Firefox from all my machines an go back to Mozilla 1.7x. I'll
come back when this bug is fixed.

Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.8) Gecko/20050511
Firefox/1.0.4 

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3)
Gecko/20050712 Firefox/1.0+
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3)
Gecko/20050712 Firefox/1.0+
> 
> By design, Profile Manager allows creating a profile in a preexisting directory
> that may contain user data.  When deleting the profile, Profile Manager can
> delete the entire directory and its entire contents.  In some instances users
> could delete all their user data, or even the entire hard drive.
> 
> Profile Manager gives a warning that may seem adequate to advanced users, but in
> practice, users sometimes suffer severe losses.  Here are the words of one user:
>  "It really didnt' give me any warning. It asked if I wanted to delete the
> profile and I said I did. Then everything was erased after that. There was
> nothing else I did that could have erased all of my files."  Here's the report
> from the Support Forum: 
> http://forums.mozillazine.org/viewtopic.php?p=1624166#1624166 .
> 
> This bug depends on bug 270705 , which will not be fixed.  It has been judged to
> be a feature, not a bug, but it continues to catch users, with sometimes
> devastating consequences.  Would it be asking too much to fix it?
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1.Create a new directory and put some expendable files in it.
> 2.Run Profile Manager and press <Browse> to create a new profile in that
directory.
> 3.Delete that profile.  Select delete all files.
> 
> Actual Results:  
> 1. Dialog box "Delete Profile" is displayed.  Box contains the warning "This
> option will delete the folder [folder path\name] and cannot be undone."  The
> warning starts in the middle of line 3 of 4 or more lines, and is easily
overlooked.
> 2. On pressing <OK> directory and all files in it (including non-Mozilla files)
> will be deleted.  If placed in the root directory, I believe it would delete all
> files and directories to which user has ReadWrite access.
> 
> Expected Results:  
> 1. Firefox should delete only the profile data, and never non-Firefox user data.
> 
> 2. Even if it does, considering the possible consequences, if the directory may
> have been user-created, Fx should display a very prominent warning, namely:
> 
> a. Warning should begin on a separate line.
> b. Warning should be bold.
> c. There should be a separate, prominent sentence.  Suggested wording: 
> "Warning:  pressing <OK> may cause loss of all or part of your user files."


>"Warning:  pressing <OK> may cause loss of all or part of your user files."

This doesn't explain, what will be done and is not resolute enough.

It should be more like this:
--------
Warning:  pressing <OK> can delete all your files!

It will remove the directory /xyz and everything in it.
--------




hi guys, i appreciate someone carres about this bad Firefox behaviour...
Just wanted to tell you that i left a comment at bug 270705
https://bugzilla.mozilla.org/show_bug.cgi?id=270705#c14 which includes two
possible solutions which are a bit different to the solutions proposed here, so
maybe this are usefull additional ideas (sorry for x-posting, i keep it short),
so here are the possible solutions:

1. There should be a warning when a non-empty folder or even a system folder (my
documents, desktop, windows or maybe even the root directory) is selected as
path to new profilefolder, because this is the point where all the trouble
begins or 
2. When pressing 'choose folder'in the profile manager, 'my documents' should
NOT be selected in the treeview by default, it should be the folder proposed by
the profilemanager in application data. This would be the standard design for
such things! When installing Firefox and you want to choose the path to program
folder, the proposed folder %programfiles%\Mozilla Firefox is selected in the
treeview by default, too.
Blocks: 304290
I reconsidered my suggestion in Comment#9, the fact that 'My Documents' is
selected in the treeview of the chhose-folder option is a bug of it's own which
is now reported: Bug 304290

In fact this is not the real solution of the problem, but it makes less people
walking into this trap: in 3 of 4 cases i read about dataloss by deleting
profile, the 'My Documents' folder was the profilefolder.

So I support including a better warning before deleting files, but actually it
should never come to a critical situation, so people shouldn't selected data
containing folders as their profilefolder.

Bug 278230 and Bug 304290 have an approach more from that direction, so IMHO it
shoulb be fixed:
( Bug 302087 AND ( Bug 304290 OR Bug 278230 )) OR Bug 270705
Depends on: 278230
I have added a companion bug 305551.  Two bug reports may seem like overkill,
but a warning when creating the profile would prevent users from comingling
files in the first place.  However, this bug fix would protect users who have
already comingled files.

I believe it would still be preferable to prevent Fx from deleting files it does
not "own" (bug 278230).
*** Bug 278230 has been marked as a duplicate of this bug. ***
Flags: blocking1.8b4?
Profile Manager is not exposed by default to regular users so this isn't going
to block our release. people capable of finding and using profile manager should
be able to avoid this dataloss issue.
Flags: blocking1.8b4? → blocking1.8b4-
I am not saying the bug should block this or that, but 'people capable of 
finding and using profile manager should be able to avoid this dataloss issue' 
sounds more as a joke to me. People are able to find and use a lot nowadays 
and this lot should not delte their files. It's one thing if they find out how 
to infect their own PC purposfully with a deadliy virus which formats their 
hard drive, but this is the browser that says it's the greatest browser of all 
times.
This is not the place for debating decisions.  Please limit your comments to
getting this bug fixed.  And please do not do things like blocking releases
unless you are sure you are in the loop.

Thanks.
(In reply to comment #13)
> Profile Manager is not exposed by default to regular users so this isn't going
> to block our release. people capable of finding and using profile manager should
> be able to avoid this dataloss issue.

zuh? You can learn to access it w/ something like 3 mouseclicks...
http://www.mozilla.org/support/firefox/edit#profile
See also bug 234680, comment 20, "Uninstall should give the option to remove
profile data".  It was pointed out that allowing user to select which data to
remove would automatically protect user files by removing only targeted profile
files.
No longer depends on: 270705, 278230
Can anyone confirm if this will affect Thunderbird in the same way as Firefox profile manager?  I am guessing that it will, which bumps up it's impact somewhat...

(In reply to comment #18)
> Can anyone confirm if this will affect Thunderbird in the same way as Firefox
> profile manager?  I am guessing that it will, which bumps up it's impact
> somewhat...
> 
I can confirm that the Thunderbird Profile Manager behaves the same way.  I tested with a current Tbird 1.5 branch  build (20051125) using the same "Steps to Reproduce" given above.  The results were the same after deleting the profile using the "Delete Files" option: the profile directory and all files in it (including non-Mozilla files) were deleted. 
In that case, I think you should file a bug for Thunderbird too, and reference this one.
(In reply to comment #20)
> In that case, I think you should file a bug for Thunderbird too, and reference
> this one.
> 
I found Thunderbird Bug 308523 which is a duplicate of "Core" bug 273729 and added a comment to the "Core" bug.


This patch makes the dialog talk about a "folder" instead of just the "files" and adds a nice "WARNING" right before the buttons (where "Don't Delete Folder" should be selected by default already).

Alternative wordings are welcome. I won't request review unless you all agree more or less.

BTW: There's no way of getting that warning in bold (unless a special message box is created for this single warning - which I won't do).
(In reply to comment #22)
> Created an attachment (id=208741) [edit]
> "Delete Folder" and more prominent WARNING
> 
> This patch makes the dialog talk about a "folder" instead of just the "files"
> and adds a nice "WARNING" right before the buttons (where "Don't Delete Folder"
> should be selected by default already).
> 
Any chance of replacing the existing three buttons in the dialog box ("Don't Delete Files", "Delete Files"  and "Cancel") with only two buttons, "OK" (which would replace the "Don't Delete Files" button) and "Cancel"?  As it is now, users  press the "Delete Files" button carelessly, because they think they know what they are doing (deleting a profile). I would suggest making "Delete Folder" a separate checkbox next to the WARNING message. That way,  the careless user will just click "OK" without reading anything, with no harm done.
(In reply to comment #22)
Did you perhaps attach the wrong file?

Don't worry about the bold face.  It doesn't matter as long as the warning is prominent.  I agree with comment 23, although I would be willing to settle for anything I can get.
Oops, that was part of the patch for bug 305551.

As for the checkbox: since the profile manager is aimed at people who know what they're doing, I prefer not make deleting a profile even one click more complex. Anyway, I'm sure that you'd still find people who actually read the checkbox' caption and decide to get rid of all their profile data - although that is located in "My Documents".

I'd rather try to get a reasonable fix for bug 305551, so that people don't even get into the situation of risking to delete valuable files...
Attachment #208741 - Attachment is obsolete: true
Is the patch ready for review?
Attachment #209166 - Flags: review?(mconnor)
I would suggest another \n character before the last line, so it really stands out.

Now that we have the correct patch in there, maybe we can get a few more people to look at it.
Maybe this shouldn't be reviewed quite yet.  The correct patch was just posted, and people need a little time to see it and comment.  There are already some helpful comments in MozillaZine:  http://forums.mozillazine.org/viewtopic.php?t=331298&start=105 .  There's nothing to lose by waiting another few days.
Attachment #209166 - Flags: review?(mconnor)
Attached image screenshot (obsolete) — 

    
    

    
  
Can someone with editbugs permissions please add the uiwanted keyword to this bug?

    
  
Keywords: uiwanted

    
    

    
  
For better or worse, most of the discussion over the patch has taken place in the Firefox Support Forum:  http://forums.mozillazine.org/viewtopic.php?p=2040231#2040231 .  Other help or discussion is certainly welcome either here or in the forum.  It is not necessary to register to post on the forum.

    
    

    
  


  
This patch includes most suggestions from the discussion in the forum: the text has been shortened, "certificates" has been replaced with "bookmarks", "Don't Delete Files" now simply reads "OK", "Delete Files" is either "Delete Folder" or "Delete 'folder-name'" (depending on the folder's location). The WARNING still remains - though now in place of the question (which has been removed).

With this patch the whole dialog is more streamlined, easier to read and thus (so we hope) more apt for keeping those users, who already created the profile in the wrong place, from deleting valuable data.

        Attachment #209166 -
        Attachment is obsolete: true

        Attachment #211073 -
        Flags: ui-review?(mconnor)

    
    

    
  
(In reply to comment #32)
> Created an attachment (id=211073) [edit]
> update as per comments in MozillaZine thread
> 
> This patch includes most suggestions from the discussion in the forum: the text
> has been shortened, "certificates" has been replaced with "bookmarks", "Don't
> Delete Files" now simply reads "OK", "Delete Files" is either "Delete Folder"
> or "Delete 'folder-name'" (depending on the folder's location). The WARNING
> still remains - though now in place of the question (which has been removed).
> 
> With this patch the whole dialog is more streamlined, easier to read and thus
> (so we hope) more apt for keeping those users, who already created the profile
> in the wrong place, from deleting valuable data.
> 

From the patch "You may also choose to delete the profile folder and its content, including your settings, bookmarks and other data." I assume that's a typo, and it's supposed to be "contents". I'm glad to see you used "other data" instead of "other user-related data", it's both shorter and it avoids implying that the deletion will be selective. It needs to be totally clear that all data in that folder will be deleted.

    
    

    
  
Note:Profile Manager is exposed to regular users who don't understand it, not by the default gui, but info is readily available.

(In reply to comment #29)
> Created an attachment (id=209477) [edit]
> screenshot
 
**Should definitely refer to folder not files. AKA "Delete Folder"
**Question mark icon could be warning to show importance of decision.
**An option to "Open Folder" or "Inspect Folder" could be useful to see what's in it, and be able to move what you what to keep, and the message should remain displayed.
**The actual folder should be displayed not in the middle of the info but near final strong warning, just above or below the buttons.
**Use "Open Folder" "Keep Folder" "Delete Folder" and "Cancel" for button text.
**"Delete Folder" should goto "Recycle Bin" so they can be likely be recoverd even with the warning that they can not, see related bug 18927 

Suggested display:
 ! Warning icon, information stating (warning) what will or can be deleted, and general information text describing options and actions of the buttons, followed by a spacer line, final STRONG WARNING, actual folder and buttons similar to below.

WARNING: "Delete Folder" CAN NOT be undone! DO NOT "Delete Folder" unless you are certain that it contains no valuable data!

"C:\Documents and Settings\All My Important files"
"Open Folder"  "Keep Folder"  "Delete Folder"  "Cancel"


    
    

    
  

      
      
      
      

        Attached image
          
        screenshot #2
        — 
      

    


  
The lower dialog appears if the profile folder was created in the default location, otherwise you get the upper dialog which repeats the folder name in a more prominent position (on the button itself).

(In reply to comment #34)
> Note:Profile Manager is exposed to regular users who don't understand it, not
> by the default gui, but info is readily available.

So is Windows' registry editor. And on the sites referring to that one, there are usually the same warnings to take care when using it as are (or should) be on the sites referring to the profile manager. Note that the problem is alleviated by the fixing of bug 304290 and should be mostly gone when bug 305551 is fixed.

> **Question mark icon could be warning to show importance of decision.

AFAIK this isn't currently possible without creating a new dialog specifically for this decision - and I don't know how drivers would like that (yet another rarely used dialog to test and maintain).

> **An option to "Open Folder" or "Inspect Folder" could be useful to see what's
> in it, and be able to move what you what to keep, and the message should remain
> displayed.

Many of those users you'd like to protect from themselves here won't be able to tell if they still need cert8, prefs, signons or (should they spot it) bookmarks. And this option would definitively require a dialog specifically for this decision.

> **"Delete Folder" should goto "Recycle Bin" so they can be likely be recoverd
> even with the warning that they can not, see related bug 18927

This won't happen here.

        Attachment #209477 -
        Attachment is obsolete: true

    
  
Flags: blocking-firefox2?

    
    

    
  
not a blocker, profile manager continues to exist for developers and QA only.  Will try to look at the patch later.
Flags: blocking-firefox2? → blocking-firefox2-

    
    

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

    
    

    
  
Several users in our company using Firefox for testing had problems with their profiles. So the profile manager will be used here. If this bug is not solved, it prohibits a widespread use of Firefox in our company, because the possible damage is to extensive.

    
    

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

    
    

    
  
Comment on attachment 211073 [details] [diff] [review]
update as per comments in MozillaZine thread

Moving this off mconnor's plate in the hope of getting things rolling for Toolkit 1.9.

(In reply to comment #36)
> profile manager continues to exist for developers and QA only. 

Only as far as Firefox is concerned -- and even on Firefox' release notes the profile manager is mentioned to all users!

        Attachment #211073 -
        Flags: ui-review?(mconnor)

        Attachment #211073 -
        Flags: ui-review?(beltzner)

        Attachment #211073 -
        Flags: review?(gavin.sharp)

    
    

    
  
Yeah my friend's just fallen victim to this horrible "feature"! There's clearly not enough advance warning -- and besides, surely such "advanced" corp sysadmins could just as easily cope with non-default behaviour that is hidden behind an "Advanced" tab or something, so that the average user who needs to use the Profile Manager because s/he was told to do so by the Mozilla support pages and forums, can stay blissfully ignorant of this ridiculous inconsideration, WITHOUT the possibility of having any irrelevant files removed?!

    
    

    
  
The above rant was just to chip in and mention that I know someone who's had Thunderbird wipe out most of his My Documents folder.

    
    

    
  
(In reply to comment #3)
> The profile manager is not meant for normal people, or even advanced normal
> people... only for developers who know what they're doing.

The Release Notes, which are posted on the Help menu, say to create a new profile.  The first FAQ in the Release Notes also points to the bug filing instructions, which list a new profile as the first step.

We have tried to saturate the Internet with warnings, but there are places we can't reach, and this bug continues to bite people.  A single warning in the right place would be much preferable.

    
    

    
  
Comment on attachment 211073 [details] [diff] [review]
update as per comments in MozillaZine thread

Giving up on this one and hoping that the Profile manager UI gets removed completely (in bug 214675) and replaced with a friendlier extension (enabled by bug 390771).

        Attachment #211073 -
        Attachment is obsolete: true

        Attachment #211073 -
        Flags: ui-review?(beltzner)

        Attachment #211073 -
        Flags: review?(gavin.sharp)

    
    

    
  
It seems to me that there is a 'logic error' in the design of this feature which will mislead users no matter how bold the warning.

If the program DOES NOT CREATE "the directory", then it SHOULD NOT DELETE "the directory." It should not take away anything it does not create.

When an administrator is required to CREATE a special directory for this program to use, then he should, logically, also be required to DELETE the directory himself when the program would no longer need to make use of it.

It is a fine thing to take into consideration the needs of system administrators of large corporations.  And it is ALSO a fine thing to keep the logic consistent for all stages of profile management, from CREATION to DELETION.  For a very advanced user tends to be a very logical thinker, whether in the home or in the corporation.

This inconsistency in logic CAUSES someone like me to EXPECT the program to do the TOTAL OPPOSITE of what it is actually doing. For lack of better words, it goes from being very UN-automated to being very OVERLY-automated in a simplistic , unintentionally misleading, and potentially dangerous way.

So, if the lack of logic in the functioning of this feature is not corrected, I believe that the warning will have to be VERY SEVERE to save a person like me, who works with computer programs based upon the logic that I expect them to have.

So, I do beg somebody to make the warning of potential disaster a little bolder.   But when you do.....  I suspect there will be PLENTY of people who will scratch there head and say, "why in the world would a program ever want to delete a parent directory that it did not create in the first place?"

So, my recommendation is... to fix this logical error for the dignity and honor of Firefox and Thunderbird (as I believe I read that this applies to both).




    
    

    
  
(In reply to comment #45)
> It seems to me that there is a 'logic error' in the design of this feature
> which will mislead users no matter how bold the warning.

Indeed there is, and this has been pointed out for years in numerous bug reports.  Note that the best way to fix the problem was WONTFIXed years ago.

Logic has nothing to do with this.  The argument used by the drivers is circular.  They won't fix the feature because it's dangerous.  But it's dangerous because they won't fix it.

Meanwhile, creating a new profile is described on Mozilla's own support forum (support.mozilla.com), because -- among other reasons -- it instantly fixes many problems that cannot be diagnosed with safe mode.

You can save your effort, though.  We managed to fix it -- sort of -- by saturating the Internet with warnings (instead of writing one warning where it belonged).  They did at least quit pointing the profile at the desktop (bug 304290).

    
  
Blocks: 273729

    
    

    
  
OK, I'm digging this bug back up from the grave because another of my users just managed to wipe out several months worth of work by deleting their (ill-placed) profile and ticked "remove files" in the process. Bad, I know. But it could have been avoided.

(In reply to comment #3)
> The profile manager is not meant for normal people, or even advanced normal
> people... only for developers who know what they're doing. If you want to
> provide a patch which will make the warning scarier, you are welcome to reopen
> the bug, otherwise we will leave this beast to rest.

If bug 214675 ever gets resolved, great. I understand and agree with the reasoning here for wanting to wontfix this, from here to bug 270705 and bug 305551. However it doesn't seem like the profile manager is going away any time soon as some still have reasons for wanting to keep it and make it better. But if the profile manager is going to stick around, users who can figure out how to access it shouldn't have to suffer any avoidable data loss when deleting a profile.

Since this bug is still regularly popping up after all these years and the profile manager has not yet been removed, the best course of action is to at least improve the way in which it handles deletion. Currently deletion is too broad and isn't being told what exactly to look for and deletes anything in the profile path, including non-Firefox files. I don't believe bolder warnings here are going to prevent this from happening if it just does the same thing when a user decides to also delete files. Especially when that profile shares space with any other data critical or not.

The best solution I can think of for this (on windows at least) would be to delete files based on a manifest of KNOWN Firefox-related files and sub-folders which can be expected within a common profile structure. Then ONLY delete those if a user chooses the delete files/folders option and leave anything else behind. After this is done, alert the user that some files may still be left behind and require manual deletion and optionally point them at the directory which was just flushed in a confirmation dialog. That's not scary anymore, is it?

Don't yell at me Ben :) But if the profile manager isn't going away any time soon, then the only solution for the time being is to make it behave. And if users (advanced or not) are going to be poking around in it, they should be learning how to manage (and delete) any left-over profile-related data. I know it's not a clean solution but some other applications that handle multiple profiles in the same manner as described above. It wouldn't be too bad if Firefox and other Moz applications did the same here.

    
    

    
  
See the discussion in bug 398434 - Provide option to remove profiles during uninstall 

The new option to remove user profile data when Firefox 3 is uninstalled does not touch files stored in profiles created in non-relative locations like My Documents or the desktop. 

Why not handle deleting profiles via the profile manager the same way and only delete files stored in the default profile location?  This was recently discussed here: http://forums.mozillazine.org/viewtopic.php?p=3397621#p3397621 

 

    
  
Flags: wanted-firefox3.1?
Product: Firefox → Toolkit

    
    

    
  
I may be chiming in here without enough background but almost all uninstall programs can delete specific files and leave settings in place.
In this case why can't every creation log it in a uninstall file and deletion do only the logged items and delete the folder if it is empty.

I haven't been into this very far too know if this has been addressed.

    
    

    
  
a more obvious solution.  The TB selected folder is fixed.  All the user can do is select the folder to put the fixed name folder.

this still suffers in that the user can actually start manually adding and using the fixed name folder outside the scope of TB.

    
    

    
  
somebody ought to neuter the delete button immediately if not sooner until this is patched. We can't be deleting whole folders.

    
    

    
  
as more reason to fix, 
I recently had a build of shredder that was dead. The problem was in the profile directory, I don't know what it was but I had to back it up with mozbakup and create a new profile, install the later build and import the backed up data.

If we run into unknown problems in the profile directory, the first advice that will be given to non developers is to fiddle with the profile directory and after successfully working with the new one, delete the old profile directory. If it's widespread advice then we will have many unhappy non-developers

    
    

    
  
(In reply to comment #51)
> I may be chiming in here without enough background but almost all uninstall
> programs can delete specific files and leave settings in place.
> In this case why can't every creation log it in a uninstall file and deletion
> do only the logged items and delete the folder if it is empty.

To my knowledge, Firefox (and probably most other Moz apps) don't keep an active record of all files within a profile directory. Then again Moz applications aren't primarily designed to run as installers/uninstallers. While that would be nice, at present it's not so easy because currently the only record keeping done  is keeping track of installed add-ons, plugins and other important Firefox files necessary for running the current profile. 

Outside of that Firefox isn't strictly aware of what other files may or may not be present beyond those files needed to start and run a generic profile. Plugins and other Add-ons may also generate their own files on occasion and those files are even more loosely kept track of. So with that in mind, Firefox is only aware of them through their respective plugin or add-on. And the linking to any files a plugin or add-on creates could be stored in any number of ways outside of the mentioned manifest making it maddening to track at present. So no matter what is done, the folder will rarely ever become empty unless a user doesn't use plugins or other add-ons.

    
    

    
  
Phil thanks to signal me that my bug is a duplicate. I paste here the info regarding ex bug 535529.

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.1.6)
Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.1.5)
Gecko/20091204 Thunderbird/3.0

The problem is described in this example:

If you choose as profile folder the folder “important documents” and then you
delete the profile, thunderbird delete all the files stored in that folder and
not only the profile ones (so there is a data loss not only respect the e-mails
but of any important document that was stored in that folder).
I want to underline that it’s true that thunderbird displays a warning telling
what it will delete, but in any case it starts a procedure very different from
the one the user desires, it asks if you want to delete the folder but the user
launched the command with a clearly different purpose, that is to delete the
profile.
I’m not saying that the function deleting the profile doesn’t work correctly or
that there’s a lack of warning messages, I’m just pointing out the questionable
protocol that this function follows.
This doesn’t concern the subjective idea relative to the attention the user
must apply during the execution of this task but it’s objectively against every
usability directive or human computer interaction or software quality
principle.


Reproducible: Always

Steps to Reproduce:
1.Start thunderbrd -p
2.From the profile windows select "create new.."
3.Select "next"
4.Set a profile name
5.Click on "select folder"
6.Navigate to the folder where you want to put the profile (for example
"documents and settings")
7.Click on finish
8.Reopen Thunderbird -p
9.Select the profile created before and click on "delete profile.."
10. Click on delete file (Because you want to delete the file relative the
profile)
Actual Results:  
Thunderbird delete all the files and subfolder contained in "document and
settings". :|   

Please read the details that I put to understand exactly what is the problem
that I point out.

Expected Results:  
Thunderbird delete only the files relative to the profile that I have decided
to delete.

SUGGESTION:
When a user create a new profile thunderbird could ask to select the folder
where are contained all the profiles (actually ask for the folder that will
contain only the profile that is being create) and create in the profile in a
subfolder with the profile's name.

Example: If i create a profile named "MYProfile" and select the folder
"document and settings" actually tb use this structure:
..\document and settings\<files of the profile>
whit this change it create this structure
..\document and settings\MYProfile\<files of the profile>

    
  
Depends on: 470927

    
    

    
  
Folks, Mozilla is not interested in fixing this bug, and may be eliminating (or replacing?) the entire Profile Manager UI in any case.

Further discussion in this bug is probably fruitless.  Comments are better placed here:

http://groups.google.de/group/mozilla.dev.planning/browse_thread/thread/06900b8b97c2655d

Be careful to acquaint yourself with the issues before commenting, if you have not done so already.

    
    

    
  
Duplicate with one addition, it really shouldn't even delete other profiles if they happen to exist under the folder. My 3 months and 2GB worth of mail would have been saved if it had so much as noticed a whole second set (and 3rd, and 4th) separate set of profiles under there. Giuseppe Tino's suggestion from December would have even saved me because the mistake of just choosing the top of the profile tree would have resulted in a sub folder anyway. I believe this bug is much more dangerous for those of use who had assumed that creating the profile in the profiles tree would already do what Giuseppe suggested. Like I said in my posting, I just wanted it to clean up all the files it dumped in the wrong place. I am a network admin, and not a terrible one at that, this behavior caught me be surprise. In fact initially I thought it had decided to delete a different profile than I selected and then realized it was just doing a blind recursion into all the sub folders. Please keep this bug report alive guys. I was so **** that I was ready to give up on client side email altogether! Though I do now realize that this is clearly a plague for only more advanced users, and am still not ready to sell my soul to the cloud.

Thanks. If I thought it were easy to get into the dev tree and fix this myself I would. I honestly just don't know where to begin with that process. I'm quite keen to contribute to OpenSource nowadays, though like all of us busy, especially when I have to reconstruct 3 months of email data. :-\

    
    

    
  
You know, if this thing is for advanced users anyway, then why not just pop open the profile folder and tell them to manually delete the files? At least that inconvenience would not have data loss at the hands of Thunderbird code as a consequence. Though I still think a few tweaks to the deletion logic that is currently blind and recursive, would nail 80% of these situations. For instance, check for prefs.js in the root of the folder. Look for Mail below that. If prefs.js is found in any sub-folder then leave that branch alone! If any files are found with non-profile types or extensions then leave them alone. Funny thing is, I'm looking at the remains of my profile and realize the dumb algorithm never even got to the actual profile, it's still sitting there in the root of the profiles folder. It went straight for a somewhat obviously unrelated folder with the default naming of a different profile: gkon3rar.default.

    
    

    
  
How would this problem (or a fix for it) be affected by implementation of bug #214675?

    
    

    
  
Well, the removal of it would leave some important functionality absent and the reimplementation within Thunderbird would require consideration of this issue, so IMO this is a separate issue. In fact, chances are implementing "enhancement" #214675 would probably result in copying the code base from profile manager and just moving this problem into Thunderbird. Which seems to be the consensus on that thread, if it is removed it needs to be implemented somewhere else. If the algorithm can't be any better than it is I'd suggest removing the delete check box altogether. So long as it can create fresh profiles and set Thunderbird's defaults  it's sufficient.

    
    

    
  
OK, here's a status report in a little more detail.

(In reply to comment #65)
> Well, the removal of it would leave some important functionality absent....
Yes, Mozilla drivers have finally acknowledged this.  See comment 60.  However, the UI WILL be removed (bug 214675), so this bug is probably moot.

There is discussion of reimplementing the Profile Manager, because Mozilla employees ALSO use it!  And there is a recognition that it's used by general users for troubleshooting, etc.  There is no guarantee that it will be reimplemented.  So far, the only reimplementation taking place is a crude version that will not be suitable for troubleshooting by the general public.  See the link in comment 60.

A simple, effective fix would have been to remove the "Delete Files" button.  However, many bug reports were already WONTFIXed, etc., and this is one of two bug reports that were allowed to remain.  We thought we could get this, at least, but no luck.  Bug 470927 came later and would also have been a good way of fixing it.
Whiteboard: See comments 60 and 65 for current status

    
  
Whiteboard: See comments 60 and 65 for current status → See comments 60 and 66 for current status

    
    

    
  
This issue continues to be a problem with Firefox 4.0b11. Not much new to report, as the specific steps and issues have already been specified, namely

- creating a new profile and browsing to the default Windows XP profile directory (C:\Documents and Settings\%USERNAME%\Application Data\Mozilla\Firefox\profiles) for the target results in the profile data being depositied in that exact directory and not within a unique subdirectory
- deleting the newly-created profile to re-create a new profile within the desired subdirectory from the above default directory results in all data within the directory being deleted!

As pointed out, this has the potential to be a very serious problem for some users, and a very annoying one for others.

Removing the "delete" button or otherwise replacing its current functionality to instruct users to perform the data removal manually would seem preferable to a situation where data loss can easily occur.

    
    

    
  
Your apps not only delete profile folder (which they didn't create) unconditionally, but also FOLLOW SYMLINKS! WHY the hell they remove files NOT stored in that folder and NOT warn that they will act OUTSIDE profile?!

    
    

    
  
Alex, that appears to be an alarming aspect of the bug that I hadn't realized.  It might be worth a separate bug report to document it (even though the bug would likely be quickly closed).

If you have experienced data loss, can you please add a brief comment here to document the loss?

    
    

    
  
Just happened to delete by mistake a profile and a backup copy of the profile.  So I now must find myself a file recovery tool.

Suggestion: instead of deleting the profile folder altogether, simply move it to the trash folder of the OS.

Or make the "Don't delete file" option being the default.  But I like the idea of using features of the OS that everybody is used to use.

    
    

    
  
Would it be too hard to move the deleted files to the Trash or Recycling, instead of immediately wiping them?



    
    

    
  
Note that many other apps already create specific named folders within the selected folder. When I created a new profile under /Profiles, I expected the same behavior. Bug 470927 mentioned above and closed would match Firefox's behavior with Calibre and so on, and avoid this mess.



    
    

    
  
Whenever any application deletes user files or information without explicit warning, it remains a most serious flaw and bug.  This sort of thing needs the highest priority programmer focus at this time.



    
    

    
  
In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.


Severity: critical → --

    
    

    
  
I was sent a request to triage the severity of this bug.  However, I cannot see how to do that.  As I already stated, this should be the highest level.


Flags: needinfo?(dtownsend)
Flags: needinfo?(dtownsend)

    
    

    
  
The severity field is not set for this bug.

:mossop, could you have a look please?


For more information, please visit BugBot documentation.


Flags: needinfo?(dtownsend)
Severity: -- → S3
Flags: needinfo?(dtownsend)
Duplicate of this bug: 1886136

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: