18927 - Profile Manager should trash/recycle data files, not delete

Status: RESOLVED WONTFIX

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

Description

[Eli Goldberg]

* TITLE/SUMMARY
Profile Manager should *never* delete data files, but put in trash

* STEPS TO REPRODUCE
0) Launch the User Profile Manager
1) From the profile manager, delete a 5.x profile, choosing "Delete Files".

* RESULT
 - What happened

All data is gone. It ain't coming back.

While this would seem like a reasonable outcome given the prior command, we've
encountered a number of user scenarios in which users really wish they hadn't
done that --- in many cases, for legitimate reasons, due to our own Communicator
bugs.

As the QA lead-like person for 4.5 UPM, and from reading every one of the UPM bug
reports submitted since --- it's my opinion that users consider this to be the
biggest error in our implementation.

 - What was expected

	When profiles are deleted --- or any other file deletion --- the files
should be relocated to the Recycle Bin (Win32) or Trash Can (Mac OS), rather than
being outright irrevocably trashed.

	One of the most common horror stories among 4.x users has been data loss
resulting from a profile being incorrectly deleted --- in some cases due to user
error, and in some cases due to User Profile Manager bugs.

	Per 6.25.99 e-mail to Bhuvan from Edwin Aoki, 4.5 UPM architect:

>There are APIs on the Mac for identifying the Trash folder (using the
>FindFolder command) and the Recycle Bin on Windows (using
>SHGetSpecialFolderLocation), so this should be fairly straightforward.

* REGRESSION

 - Occurs On
        Mac OS Apprunner (11.15.99 optimized build)
        Win32 Apprunner (11.12.99 optimized build [NT 4, Service Pack 5])

* CONFIGURATIONS TESTED

- [Mac] Beige Power Mac G3 (266 MHz PowerPC 750), 96 MB RAM (VM on; 1 MB of VM
used), 1024x768 (Thousands of Colors), Mac OS 8.6

- [Win32] Vectra VL (233 MHz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP5.

- [Linux] Vectra VL (266 MHz P2), 96 MB RAM. Red Hat Linux 6.0 (GNOME).

Comment 1

[Eli Goldberg]

[QA Assigning to self.]

Comment 2

[selmer (gone)]

Bhuvan, we should make sure this is implemented at the filespec level and not
directly in our code.  If you have to implement this, do it there and just call
it from the profile manager.  I don't think this comes above your existing M12
bugs.

Comment 3

[Eli Goldberg]

[I'd personally put it in the category of "please fix before RTM" issues.
Thanks!]

Comment 4

[racham]

Accepting the bug.
Adding DougT to cc list.

Doug,
Do we already have this feature (of moving deleted files trash) in FileSpec ?

Comment 5

[leger]

Moving all Profile Manager bugs to new Profile Manager Backend component.
Profile Manager component to be deleted.

Comment 6

[racham]

Doug is in the processing of checking in the code that has some APIs to do this. 
So, I will schedule my fix/checkin after his. marking m16.

Comment 7

[racham]

At present, we have a dialog that asks whether to delete the files or not. Then 
once ben checks in fix for bug 30156 (I posted a fix), user gets confirmation 
dialog with the path of the profile directory displayed and text about the 
deletion. Choosing to delete at this stage should be intentional.

Also on the nsIFile end (a better nsFileSpec impl), moving directories to 
another directory is not there. I spoke to cathleen and it looks like not such a 
feature might not get in anytime now. The alternative will be move file by file 
to trash folder..which I believe is not at all efficient. Windows APIs return 
recycle bin's parent folder and it is a virtual folder. Couldn't move stuff 
using movetoDir API (may be because the it is a virtual folder). But we should 
definitely think about the implementation. Considering the cycles left for other 
bugs, work involved on various front to fully implement this and the necessity 
for this have in the product at this point are not encouraging to pursue further 
at this point. Marking this as an enhancement and moving this to M20.

Moving this bug

Comment 8

[Eli Goldberg]

I think that relies on at least three assumptions:

#1: The directory path supplied to the user will in fact be the list that 
Netscape 6/Mozilla does in fact remove.

#2: The user is able to look at the path and intelligibly conclude that whether 
or not they want files in that path deleted. This may be the case for many 
Netscape employees, but most of the users of Netscape 6 will not be able to tell 
the difference.

#3: If some software bug *once again* results in an invalid path being displayed 
to the user (such as a path that would yield undesired data loss), the user will 
be able to discern this from the information presented, and avoid nuking a major 
chunk of their hard drive.

I'm reclassifying this as 'Normal' from 'Enhancement' given the gigabytes of lost 
user data resulting from this implementation deficiency in previous releases 
(barring proof that the above three assumptions are incorrect.)

Comment 9

[Eli Goldberg]

Err, rather, barring proof that the three assumptions listed are correct.

Comment 10

[Grace Bush]

changing QA contact

Comment 11

[racham]

Doing a mass reassign to Conrad Carlen.

Conrad is going address all current and upcoming profile manager issues. Please
do not hesitate to involve me in any of the issues.

Comment 12

[Conrad Carlen (not reading bugmail)]

Moving to M 0.9 We need to agree on whether this is still valid. The current UI
lets the user know that they are deleting files when they are deleting a 5.x
profile and makes it clear that files won't be deleted with an unmigrated 4.x
profile. Isn't this enough? At most, the front-end js code could pop one more
warning after the user hits the "Delete Files" button.

Comment 13

[Conrad Carlen (not reading bugmail)]

Setting milestone to none. Since the current profile mgr UI makes it clear that
the files are going to be deleted, I'm not sure how valid this is. Not just
marking INVALID because the current UI does not give the path of the dir it's
going to delete. That would be helpful but, if so, the component would be
Profile Manager FrontEnd.

Comment 14

[Matthew T (active 1999-2002)]

Except in contractual situations, it's always better to provide undo than to 
require confirmation; users don't read alerts. That's why this bug is valid.

Comment 15

[Brant Gurganus]

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.

Comment 16

[Kevin Brosnan]

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

Comment 17

[VanillaMozilla]

This fix will fail because it is possible to delete the entire hard drive, which
will not fit into the Recycle Bin.

Here is a recent, credible-sounding report of loss of the entire hard drive: 
http://forums.mozillazine.org/viewtopic.php?t=296159&postdays=0&postorder=asc&postsperpage=15&start=0
.  There are other recent reports of loss of most or all user files.

Evidently a warning isn't sufficient.  The current warning isn't sufficiently
prominent, and users are not alert to the possibility that Firefox could cause
catastropic damage.  Bug 302087 requests a more prominent warning.  Bug 278230
suggests creating a subdirectory to prevent catastrophic behavior.

Comment 18

[VanillaMozilla]

Confirmed for a recent build.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050712
Firefox/1.0+

Comment 19

[Spencer Selander [greenknight]]

In the case cited in comment #17, when the user was pressed to clarify his
statement that he lost all files, it turned out he only lost the contents of his
My Documents folder. It was not a case of deleting the entire hard drive, as it
sounded like at first, though that could still amount to a lot of data. 

Comment 20

[shadytrees]

For the Windows API, use SHFileOperation instead of moving a file to recycle it.
FO_DELETE in SHFILEOPSTRUCT can recycle stuff without having to move stuff to
the bin.

Comment 21

[Kevin Brosnan]

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

Comment 23

[chris mckenzie]

I lost a serious amount of data with this bug.  The problem is that the profile deletion is an rm -fr on everything.

Here is how you replicate something really reasonable:

1. Create a new profile.
2. Create a directory say c:\important\profiles.
3. Accidentally pick c:\important.

Now c:\important will be populated with everything you want to be in c:\important\profiles.

So you want to undo that.  Delete the profile.

Oops, that was rm -fr c:\important.

- This is absolutely ridiculous.  I lost a days worth of code and months worth of notes because someone wasn't careful enough to just delete what they created.  This kind of bug is about as bad as it gets.

I'd rather have firefox crash every 1/10th of a second then wipe out months of work.  Thanks.

Comment 24

[Jacques Boucher]

I experienced the same problem as in comment #23, but on a MS Windows system.  I created a new profile to demo something to someone.  I selected an existing folder which had other data in it (important data - I shouldn't have been so hasty to select that folder, but didn't expect the end result of losing everything).  When I was done with the demo I deleted the folder.  Shortly thereafter I went looking for stuff in that folder and noticed that the folder was gone.  FF deleted that entire folder without any prompting/warning whatsoever, and without ensuring that it deleted what it created.  It deleted everything - a few gigs worth of stuff.  Luckily I had most of the stuff backed up and what wasn't backed up was work in progress that wasn't particularly critical.  But I still was not impressed at all.

Firefox should:
1 - warn the user that the action of deleting a profile will delete everything in that profile folder and below it.
2 - alternatively Firefox could only delete what it created.  However I understand the challenge becomes extensions and the likes.

So of the two option 1 is easiest to implement.

I agree with the original bug suggestion (1999??? and still doing the same thing) of dumping it to the trash bin so at least a user has the opportunity to recover it.  But in addition to that make sure the user is warned about the folders that will be indiscriminately deleted when the profile is deleted.

Comment 25

[Jacques Boucher]

Correction to my posting under comment #24, "When I was done with the demo I deleted the folder." should read "When I was done with the demo I deleted the profile from within profile manager."