After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 41850 - Trash should follow fdo trash spec (adds restoring facilities)
Trash should follow fdo trash spec (adds restoring facilities)
Product: nautilus
Classification: Core
Component: Trash
Other All
: High enhancement
: future
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 41851 48033 107388 125090 132016 136318 168702 171767 327664 329081 446070 474071 478274 515491 521553 535877 (view as bug list)
Depends on: 41852 518573
Reported: 2000-08-01 15:36 UTC by Maciej Stachowiak
Modified: 2015-11-14 16:46 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14

Description Maciej Stachowiak 2001-09-10 00:34:03 UTC
Items in the trash should have an "undelete" operation that will restore the
item to the original name and location.

------- Additional Comments From 2000-08-01 18:44:36 ----

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

------- Additional Comments From 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

------- Additional Comments From 2000-10-16 19:43:17 ----

Batch-assigning QA ownership of remaining bugs to

------- Additional Comments From 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 2001-03-26 11:20:30 ----


(Jon Allen has taken these components; QA Assigning bugs to him.)

------- Additional Comments From 2001-03-31 02:58:16 ----

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 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 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 2001-09-09 20:34 -------
Comment 1 Benedikt Roth 2001-10-28 13:13:14 UTC
*** Bug 48033 has been marked as a duplicate of this bug. ***
Comment 2 Mark Finlay 2003-02-03 19:46:23 UTC
Would be great to see this looked at for 2.3
Comment 3 Alexander Larsson 2003-03-19 16:56:18 UTC
*** Bug 107388 has been marked as a duplicate of this bug. ***
Comment 4 Martin Wehner 2003-10-31 12:59:44 UTC
*** Bug 125090 has been marked as a duplicate of this bug. ***
Comment 5 Thomas Vander Stichele 2003-10-31 15:07:21 UTC
*** Bug 125090 has been marked as a duplicate of this bug. ***
Comment 6 Matthew Gatto 2004-01-20 18:51:31 UTC
*** Bug 132016 has been marked as a duplicate of this bug. ***
Comment 7 Matthew Gatto 2004-03-05 22:34:33 UTC
*** Bug 136318 has been marked as a duplicate of this bug. ***
Comment 8 TuringTest 2005-02-15 17:53:24 UTC
"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.
Comment 9 Martin Wehner 2005-03-01 10:25:27 UTC
*** Bug 168702 has been marked as a duplicate of this bug. ***
Comment 10 Sebastien Bacher 2005-03-27 10:07:49 UTC
*** Bug 171767 has been marked as a duplicate of this bug. ***
Comment 11 fast suzuki 2005-04-12 23:12:49 UTC
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.
Comment 12 Matthew Paul Thomas (mpt) 2005-04-27 16:50:00 UTC
If you want Undow, please file that as a separate bug. Restore should still work
independent of the undo history.
Comment 13 Luis Villa 2005-07-10 04:28:37 UTC
Please don't set the gnome milestone unless you think the entire gnome release
should be held for the bug.
Comment 14 Christian Neumair 2005-07-12 19:08:38 UTC
The freedesktop trash spec [1] should be implemented.

Comment 15 Matthew East 2005-07-21 21:32:21 UTC
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.
Comment 16 Christian Neumair 2005-07-21 21:41:42 UTC
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.
Comment 17 Stefano 2005-11-19 14:28:57 UTC
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.
Comment 18 Christian Neumair 2005-11-19 14:56:48 UTC
bluefuture: That's exactly what the 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.
Comment 19 Fabio Bonelli 2006-01-29 19:55:51 UTC
*** Bug 329081 has been marked as a duplicate of this bug. ***
Comment 20 Thomas Winwood 2006-01-29 22:02:28 UTC
Wow. This has been around since 2.3?!
Comment 21 Christian Neumair 2006-01-29 22:24:16 UTC
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.
Comment 22 Joachim Noreiko 2006-02-24 13:52:49 UTC
Would adding a 'Date Deleted' column to Trash list view come under this?
Comment 23 Teppo Turtiainen 2006-02-26 14:21:52 UTC
*** Bug 327664 has been marked as a duplicate of this bug. ***
Comment 24 towsonu2003 2006-11-11 04:35:15 UTC
Hi, Ubuntu is also getting requests for this enhancement:

And some users seem to be struggling with recovering accidentally-deleted-files from trash ( ) 

Thanks for the effort :)
Comment 25 Oded Arbel 2007-02-11 15:47:57 UTC
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).
Comment 26 Vincent Untz 2007-06-10 19:51:43 UTC
*** Bug 446070 has been marked as a duplicate of this bug. ***
Comment 27 alexandreracine 2007-07-08 19:25:48 UTC
I want to know too and I support morally whoever implement this :)
Comment 28 Dan Kegel 2007-08-20 19:10:00 UTC
Looks like  Alexander Larsson might be working on this as part
of gvfs:
Comment 29 chuchiperriman 2007-11-24 17:26:36 UTC
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.

Comment 30 Cosimo Cecchi 2007-12-26 23:35:50 UTC
*** Bug 478274 has been marked as a duplicate of this bug. ***
Comment 31 Cosimo Cecchi 2008-01-12 11:22:45 UTC
*** Bug 474071 has been marked as a duplicate of this bug. ***
Comment 32 Cosimo Cecchi 2008-02-10 12:18:52 UTC
*** Bug 515491 has been marked as a duplicate of this bug. ***
Comment 33 Dick Gevers 2008-02-10 13:12:33 UTC
Until this is fixed the GNOME wastebasket is a poor imitation of the mswindows recycle bin.
Comment 34 Luca Ferretti 2008-02-25 10:13:14 UTC
Opened a bug against glib/gio for a g_file_restore_from_trash() function.
Comment 35 Cosimo Cecchi 2008-03-10 15:36:57 UTC
*** Bug 521553 has been marked as a duplicate of this bug. ***
Comment 36 Soroush _ 2008-04-20 09:31:25 UTC
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.
Comment 37 Fabricio Godoy 2008-05-31 07:08:25 UTC
*** Bug 535877 has been marked as a duplicate of this bug. ***
Comment 38 Christian Neumair 2008-07-21 15:00:55 UTC
This has been implemented in trunk

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.