GNOME Bugzilla – Bug 381517
.Trash-$USER does not behave as expected on non-fixed volumes
Last modified: 2010-01-24 01:07:07 UTC
Please describe the problem: When empty trash is selected, .trash-$USER is not cleared on gnome-volume-manager mounted volumes. Suggested as critical because user is not aware of the hidden trash, and does not seem to have any files, or free space on their removable volume. This problem has been reproduced in several versions of gnome, using ubuntu. Steps to reproduce: 1. Right click on a bunch of files, select "move to trash" 2. Right click on the trash can on the taskbar, and select to empty it. Actual results: .trash-$USER is not cleared, resulting in the files not being unlinked from the volume, and the volume not being cleard for re-writing. Expected results: Expected result is all files in .trash-$USER on the removable volume being unlinked and df reporting more space free on the volume :) Does this happen every time? yes. Other information: i did do some searches to try not to duplicate another bug, but to my suprise, i did not find a duped bug, mabye i havent searched hard enough, but i have experienced this problem on a lot of systems
don't see how this is a g-v-m bug...?
That may be, but if not, whose bug is this? I can repost it, but it is a major usability issue, and it shouldnt be ignored.
Related to bug 138058.
This happens with the trash panel applet. (tested 2.16.2) Emptying the trash with nautilus "File -> Empty Trash" works as expected.
More info: If the removable drive does not have a .Trash-$USER when it's mounted the trash applet does not monitor the trash on that drive. This means that the trash applet is not aware of items moved to the trash after mounting. This is a gnome-applets bug, not nautilus.
Created attachment 81848 [details] [review] Monitor newly mounted volumes for creation of .Trash-$USER
There is still a bug somewhere in this patch. Using a keyring with no .Trash-davyd (thanks OSDL!), I deleted the files on it. Trashapplet didn't notice. I then undeleted the files, and removed the empty .Trash-davyd and unmounted the volume. I remounted the volume and deleted the files. This time Trashapplet did notice. I undeleted the files again and removed .Trash-davyd and then restarted Trashapplet. I got the same results, so it suggests that something doesn't work the first time through. I'm not sure if it's the first time through for any removable volume or for each specific removable volume.
The new GVFS trash backend takes care of presenting all volumes under a unified trash:/.