Last Comment Bug 302087 - Inadequate warning before Profile Manager deletes non-Mozilla files
: Inadequate warning before Profile Manager deletes non-Mozilla files
Status: NEW
See comments 60 and 66 for current st...
: dataloss, uiwanted
Product: Toolkit
Classification: Components
Component: Startup and Profile System (show other bugs)
: unspecified
: All All
: -- critical with 30 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
: 278230 336226 338495 340457 355918 452463 486834 535529 563667 622279 1116291 (view as bug list)
Depends on: 470927
Blocks: 273729 304290
  Show dependency treegraph
 
Reported: 2005-07-25 13:48 PDT by VanillaMozilla
Modified: 2016-04-03 18:57 PDT (History)
33 users (show)
asa: blocking1.8b4-
u88484: wanted1.9.1?
mconnor: blocking‑firefox2-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
"Delete Folder" and more prominent WARNING (2.05 KB, patch)
2006-01-17 09:16 PST, Simon Bünzli
no flags Details | Diff | Splinter Review
"Delete Folder" and more prominent WARNING (2.17 KB, patch)
2006-01-20 17:04 PST, Simon Bünzli
no flags Details | Diff | Splinter Review
screenshot (7.48 KB, image/png)
2006-01-24 12:30 PST, Simon Bünzli
no flags Details
update as per comments in MozillaZine thread (4.51 KB, patch)
2006-02-07 16:09 PST, Simon Bünzli
no flags Details | Diff | Splinter Review
screenshot #2 (26.97 KB, image/png)
2006-03-04 16:54 PST, Simon Bünzli
no flags Details

Description VanillaMozilla 2005-07-25 13:48:05 PDT
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."
Comment 1 Iavor Raytchev 2005-07-25 14:53:07 PDT
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.
Comment 2 VanillaMozilla 2005-07-25 15:14:46 PDT
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.
Comment 3 Benjamin Smedberg [:bsmedberg] 2005-07-25 15:31:49 PDT
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.
Comment 4 Iavor Raytchev 2005-07-25 15:54:04 PDT
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.
Comment 5 VanillaMozilla 2005-07-26 05:18:40 PDT
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.
Comment 6 VanillaMozilla 2005-07-31 10:22:55 PDT
Reopening and attaching dataloss keyword.  This is a nasty bug.  See also bug
278230.
Comment 7 Hayo 2005-08-09 01:24:29 PDT
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."

Comment 8 Andreas Koller 2005-08-09 18:13:58 PDT
>"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.
--------



Comment 9 Tobias Caspers 2005-08-10 23:04:13 PDT
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.
Comment 10 Tobias Caspers 2005-08-12 03:21:05 PDT
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
Comment 11 VanillaMozilla 2005-08-22 15:55:17 PDT
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).
Comment 12 Benjamin Smedberg [:bsmedberg] 2005-08-23 08:12:29 PDT
*** Bug 278230 has been marked as a duplicate of this bug. ***
Comment 13 Asa Dotzler [:asa] 2005-08-31 15:19:40 PDT
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.
Comment 14 Iavor Raytchev 2005-08-31 15:39:52 PDT
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.
Comment 15 VanillaMozilla 2005-09-01 05:52:07 PDT
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.
Comment 16 hhh 2005-09-02 07:31:07 PDT
(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
Comment 17 VanillaMozilla 2005-09-02 13:25:14 PDT
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.
Comment 18 Reuben Farrelly 2005-11-30 18:43:05 PST
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...
Comment 19 Alice Wyman 2005-12-05 15:47:41 PST
(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. 
Comment 20 VanillaMozilla 2005-12-09 14:58:29 PST
In that case, I think you should file a bug for Thunderbird too, and reference this one.
Comment 21 Alice Wyman 2006-01-13 07:38:13 PST
(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.

Comment 22 Simon Bünzli 2006-01-17 09:16:33 PST
Created attachment 208741 [details] [diff] [review]
"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).

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).
Comment 23 Alice Wyman 2006-01-17 11:57:31 PST
(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.
Comment 24 VanillaMozilla 2006-01-20 16:41:28 PST
(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.
Comment 25 Simon Bünzli 2006-01-20 17:04:46 PST
Created attachment 209166 [details] [diff] [review]
"Delete Folder" and more prominent WARNING

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...
Comment 26 u88484 2006-01-22 11:05:41 PST
Is the patch ready for review?
Comment 27 VanillaMozilla 2006-01-23 12:39:21 PST
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.
Comment 28 VanillaMozilla 2006-01-24 06:08:19 PST
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.
Comment 29 Simon Bünzli 2006-01-24 12:30:11 PST
Created attachment 209477 [details]
screenshot
Comment 30 Rishi Maharaj 2006-02-01 20:08:08 PST
Can someone with editbugs permissions please add the uiwanted keyword to this bug?
Comment 31 VanillaMozilla 2006-02-03 11:38:52 PST
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.
Comment 32 Simon Bünzli 2006-02-07 16:09:39 PST
Created attachment 211073 [details] [diff] [review]
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.
Comment 33 Spencer Selander [greenknight] 2006-02-09 04:38:21 PST
(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.
Comment 34 max1million 2006-03-04 16:15:53 PST
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"
Comment 35 Simon Bünzli 2006-03-04 16:54:12 PST
Created attachment 214042 [details]
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.
Comment 36 Mike Connor [:mconnor] 2006-03-21 21:42:30 PST
not a blocker, profile manager continues to exist for developers and QA only.  Will try to look at the patch later.
Comment 37 Ryan Flint [:rflint] (ping via IRC for reviews) 2006-05-02 00:59:33 PDT
*** Bug 336226 has been marked as a duplicate of this bug. ***
Comment 38 Wolfgang Killinger 2006-05-02 01:04:34 PDT
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.
Comment 39 Ryan Flint [:rflint] (ping via IRC for reviews) 2006-05-18 17:38:03 PDT
*** Bug 338495 has been marked as a duplicate of this bug. ***
Comment 40 Simon Bünzli 2007-02-09 19:42:40 PST
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!
Comment 41 Marc 2007-03-22 17:32:17 PDT
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?!
Comment 42 Marc 2007-03-22 17:34:09 PDT
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.
Comment 43 VanillaMozilla 2007-04-11 10:59:51 PDT
(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 44 Simon Bünzli 2007-08-11 03:14:21 PDT
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).
Comment 45 Robert Sfredda 2007-12-29 05:45:22 PST
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).


Comment 46 VanillaMozilla 2007-12-31 15:41:59 PST
(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).
Comment 47 Lech Deregowski [:lech] 2008-06-23 12:14:19 PDT
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.
Comment 48 Alice Wyman 2008-06-23 13:51:15 PDT
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 

 
Comment 49 Wayne Mery (:wsmwk, NI for questions) 2008-10-10 11:12:37 PDT
*** Bug 452463 has been marked as a duplicate of this bug. ***
Comment 50 Wayne Mery (:wsmwk, NI for questions) 2008-10-10 11:13:54 PDT
*** Bug 340457 has been marked as a duplicate of this bug. ***
Comment 51 Phil Lacy 2008-12-26 07:33:06 PST
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.
Comment 52 Phil Lacy 2008-12-26 08:05:15 PST
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.
Comment 53 Matthias Versen [:Matti] 2009-05-01 08:09:53 PDT
*** Bug 490979 has been marked as a duplicate of this bug. ***
Comment 54 Phil Lacy 2009-12-12 10:41:20 PST
somebody ought to neuter the delete button immediately if not sooner until this is patched. We can't be deleting whole folders.
Comment 55 Phil Lacy 2009-12-12 10:47:18 PST
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
Comment 56 Lech Deregowski [:lech] 2009-12-13 04:57:41 PST
(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.
Comment 57 Phil Ringnalda (:philor) 2009-12-18 07:13:41 PST
*** Bug 535529 has been marked as a duplicate of this bug. ***
Comment 58 Giuseppe Tino 2009-12-18 13:29:38 PST
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>
Comment 59 Wayne Mery (:wsmwk, NI for questions) 2010-04-15 11:17:06 PDT
*** Bug 486834 has been marked as a duplicate of this bug. ***
Comment 60 VanillaMozilla 2010-04-16 13:00:44 PDT
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.
Comment 61 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2010-05-04 18:56:25 PDT
*** Bug 563667 has been marked as a duplicate of this bug. ***
Comment 62 Ryan Jameson 2010-05-04 19:37:56 PDT
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. :-\
Comment 63 Ryan Jameson 2010-05-04 19:53:45 PDT
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.
Comment 64 David E. Ross 2010-05-05 15:48:36 PDT
How would this problem (or a fix for it) be affected by implementation of bug #214675?
Comment 65 Ryan Jameson 2010-05-05 19:40:59 PDT
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.
Comment 66 VanillaMozilla 2010-05-05 20:53:16 PDT
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.
Comment 67 prakash 2011-01-08 01:10:03 PST
*** Bug 622279 has been marked as a duplicate of this bug. ***
Comment 68 David 2011-02-21 10:34:49 PST
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.
Comment 69 [:Aleksej] 2011-06-02 09:13:13 PDT
*** Bug 355918 has been marked as a duplicate of this bug. ***
Comment 70 Alex 2011-08-10 01:01:30 PDT
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?!
Comment 71 VanillaMozilla 2011-08-21 06:22:53 PDT
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?
Comment 72 Frederic Denis 2015-01-21 08:51:06 PST
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.
Comment 73 Wayne Mery (:wsmwk, NI for questions) 2016-04-03 18:57:15 PDT
*** Bug 1116291 has been marked as a duplicate of this bug. ***

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