GNOME Bugzilla – Bug 695460
Unable to restore trash if the containing directory is removed
Last modified: 2013-03-19 23:30:10 UTC
When you delete something, it goes into trash: .Trash-$UID/files/TrashedFile.ext .Trash-$UID/info/TrashedFile.ext.trashinfo The trashinfo contains the path relative to .Trash-$UID's parent directory as the location to which the trashed file or directory should be restored. Imagine accidentally trashing 1000 files, and at some point rmdir the containing directory before you realize you need to restore the trash. In other file managers like PCManFM (Lubuntu) this is no problem. The paths stored in .trashinfo will be recreated when restoring the trash if it doesn't exist. In Nautilus (and Nemo), you get 1000 popups at once saying "There was an error getting information about the destination. Details: Error when getting information for file '/mountpoint/path/to/file': No such file or directory." When having even more files in trash, the many popup dialogs cause the desktop to freeze, requiring a reboot. For every popup, you can manually do a mkdir -p '/mountpoint/path/to/file', hit "RETRY" and it will work. However, this is not feasible for anything other than a handful of files. I am not sure this bug is in the right place, or if another GNOME component handles this. If not filed correctly, please help find the right place, because it's pretty important. Forwarded from here: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1152706
Thanks for the report; I pushed a fix for this bug to git master now, will be in 3.8.0.
Appreciated!