GNOME Bugzilla – Bug 41850
Trash should follow fdo trash spec (adds restoring facilities)
Last modified: 2015-11-14 16:46:14 UTC
Items in the trash should have an "undelete" operation that will restore the item to the original name and location. ------- Additional Comments From darin@bentspoon.com 2000-08-01 18:44:36 ---- *** Bug 41851 has been marked as a duplicate of this bug. *** ------- Additional Comments From darin@bentspoon.com 2000-08-02 10:22:43 ---- As nice as this is feature would be, it doesn't seem required. This exists on the Macintosh, and as John says, "as far as I know, no one uses it." ------- Additional Comments From eli@eazel.com 2000-10-16 19:43:17 ---- Batch-assigning QA ownership of remaining bugs to eli@eazel.com ------- Additional Comments From ndt@wagonfixers.com 2001-03-17 15:02:25 ---- Perhaps nobody uses it on the Mac, but I trashed something yesterday by accident (mis-clicked while using the right-click menu) and was annoyed at having to wander through my filesystem to put it back. Perhaps there are fewer accidental deletions on the Mac to begin with? ------- Additional Comments From eli@eazel.com 2001-03-26 11:20:30 ---- SPAAAAAAAAAM! (Jon Allen has taken these components; QA Assigning bugs to him.) ------- Additional Comments From jonallen@sdf.lonestar.org 2001-03-31 02:58:16 ---- <opinion> I think this should have a higher priority. Undelete would be very benificial in cases where deleted files came from highly-nested/difficult to [find|remember] directories. Currently, restoring fils from Trash is time-consuming and non-intuitive. ------- Additional Comments From snickell@stanford.edu 2001-07-23 00:38:35 ---- Taking bugs previously assigned to Pavel, assigning them to myself. Will parse them out at my leisure , but many are GnomeVFS bugs we should look at for 2.0 ------- Additional Comments From mjs@noisehavoc.org 2001-07-23 01:17:08 ---- Move to unassigned. I'll probably want to take a crack at some of these myself, and Seth says he is unlikely to. ------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:34 -------
*** Bug 48033 has been marked as a duplicate of this bug. ***
Would be great to see this looked at for 2.3
*** Bug 107388 has been marked as a duplicate of this bug. ***
*** Bug 125090 has been marked as a duplicate of this bug. ***
*** Bug 132016 has been marked as a duplicate of this bug. ***
*** Bug 136318 has been marked as a duplicate of this bug. ***
"as far as I know, no one uses it" is not a valid reason not to implement something. "Restore" falls in the category of Undo commands, and everything command in a usable environment should be easily undoable (to allow user exploration). Actually, it's a shame that Nautilus doesn't have Undo for the Copy, Move & Rename commands.
*** Bug 168702 has been marked as a duplicate of this bug. ***
*** Bug 171767 has been marked as a duplicate of this bug. ***
Undo should always be provided even if it's rarely used. The user count on being able to correct their mistakes/bad decision if they made any by accident.
If you want Undow, please file that as a separate bug. Restore should still work independent of the undo history.
Please don't set the gnome milestone unless you think the entire gnome release should be held for the bug.
The freedesktop trash spec [1] should be implemented. [1] http://www.ramendik.ru/docs/trashspec.html
Just adding my voice to those that say this bug should have a higher status than enh. Judging by the number of duplicates, I'd say the number of users clamouring for this feature is significant.
Matthew: The problem is not that we're ignorant of the lack of this but that noone picked up work on it. It shouldn't be that hard to get something working done. We're already too late for 2.12 feature freeze so we have enough time to get a nice clean implementation.
file and directory in trash doesn't have the source path and deleting date stored. It could be helpfull to group file and directory by deleted date/time and with the source path info stored could be "rollbacked" to the original position. - other then "undo" there could be very useful to implement also a sort of "begin transaction" button in the nautilus toolbar. When you start a "transaction" you could make copy delete etc. etc. on every file. the new file and dir could be in grey colour (if it was copied to another dir there could be a tooltip with the destination directory) and the file deleted could be over impressed with a line. when you commit you could review the list transaction changes with a pop up (and before commit in the notification area?) and confirm it or rollback :) The user could access to all the last committed transaction with date-commited info, viewing the list of modification occured in the filesytem and then, if he wants "rollback" it.
bluefuture: That's exactly what the freedesktop.org spec is all about. The problem is that the GnomeVFS API and its client APIs currently don't deal with it correctly, and that's what this bug covers.
*** Bug 329081 has been marked as a duplicate of this bug. ***
Wow. This has been around since 2.3?!
Yes, because fixing it is nontrivial. One has to iron out first a GnomeVFS API for trash handling, which does all the reverting for us. We need more than a simple gnome_vfs_find_directory with GNOME_VFS_DIRECTORY_KIND_TRASH.
Would adding a 'Date Deleted' column to Trash list view come under this?
*** Bug 327664 has been marked as a duplicate of this bug. ***
Hi, Ubuntu is also getting requests for this enhancement: https://launchpad.net/distros/ubuntu/+source/nautilus/+bug/14412 And some users seem to be struggling with recovering accidentally-deleted-files from trash ( http://ubuntuforums.org/showthread.php?p=1742430 ) Thanks for the effort :)
Sorry for the bug spam (which would be sent anyway because I want to be CCed on the bug), but I wanted to add a "me too!", because all other trash implementations I know have an "undelete" option, and if its in the fdo spec then I think it should be followed. (BTW - I really like the way that the GNOME wastebasket shows the trash content from auto-mounted media, automaticalloy - kudus).
*** Bug 446070 has been marked as a duplicate of this bug. ***
I want to know too and I support morally whoever implement this :)
Looks like Alexander Larsson might be working on this as part of gvfs: http://www.mail-archive.com/nautilus-list@gnome.org/msg03787.html
Bug one since year 2000... Really, Is this so hard? I can help you if you need it. Where is the problem? Gnomevfs, gvfs or nautilus? IMO, this issue is very important for Gnome and us (the users) because in a desktop the user can be some "Clumsy" and the user NEEDS this feature to touch his linux without fears. I have installed Ubuntu to my sister's husband and he send some songs to the trash with Rythmbox. Now he has a lot of songs in the trash been every song of a different folder (all mixed). How can he reorder all his files? He cannot!! I thinks this is a very important and basic feature. Regards
*** Bug 478274 has been marked as a duplicate of this bug. ***
*** Bug 474071 has been marked as a duplicate of this bug. ***
*** Bug 515491 has been marked as a duplicate of this bug. ***
Until this is fixed the GNOME wastebasket is a poor imitation of the mswindows recycle bin.
Opened a bug against glib/gio for a g_file_restore_from_trash() function.
*** Bug 521553 has been marked as a duplicate of this bug. ***
I really wonder how gnome has lost such this wonderful feature also I see windows explorer has had it since long before. I believe this bug had a critical priority I believe that nautilus must be able to undo any command(Copy, Cut, Move to trash) and it should confirm before undoing however windows explorer doesn't confirm except when it wants to delete sth(Copy undo) but it is so nicer if nautilus could confirm it. Dolphin has this too.
*** Bug 535877 has been marked as a duplicate of this bug. ***
This has been implemented in trunk http://svn.gnome.org/viewvc/nautilus?view=revision&revision=14386 with two constraints: a) it is per-item only b) it picks the wrong file name if there are file name conflicts inside trash:///. This is due to bug 41852, which can be fixed in the gvfs trash backend. Closing as fixed.