GNOME Bugzilla – Bug 338653
Can't delete images on mounted volume
Last modified: 2007-06-05 21:23:38 UTC
Please describe the problem: A user "joe" has images stored in a directory /store/joe/photos/. The directory /store is a mountpoint for a different volume, so joe's photos are not on the same volume as joe's home directory. There is a directory /store/.Trash-joe to which joe has full permissions. joe opens an image with eog, and selects "Move to Trash" from the Edit menu. Instead of deleting the image, eog responds with "Error on deleting foo.jpg. Could n't access wastebasket." Steps to reproduce: 1. With appropriate permissions: mkdir /store mount /dev/hdxx /store mkdir /store/photos mkdir /store/.Trash-joe chown joe:joe /store/.Trash-joe /store/photos 2. Log in as user joe. Copy a jpeg to /store/photos/. Open the jpeg with eog. 3. Ask eog to move the image to the trash. Actual results: eog says it can't access the trash Expected results: eog should move the jpeg to /store/.Trash-joe Does this happen every time? Yes Other information: Nautilus and gthumb both get this right. The trash for the gnome desktop, for files located on a mounted volume, is taken to be the directory /.Trash-user at the top level of the mount, if that directory exists and has appropriate permissions. Nautilus moves the jpeg to /store/.Trash-joe without complaint.
In eog-window.c, is it perhaps the case that gnome_vfs_find_directory should be called the first time with the argument find_if_needed passed as TRUE? I wonder if this is the cause of the problem. I am only guessing, based on the description of gnome_vfs_find_directory at http://developer.gnome.org/doc/API//2.0/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-directory-find-ops.html
Created attachment 63664 [details] [review] Patch to allow use of existing .Trash-$USER directory on device Attaching a pseudo-pathch. I don't really know how to create a proper patch, but I have attached a diff obtained using "diff -rup eog-window.old.c eog-window.c" against the present 2.14.1 release (having renamed the original file as "eog-window.old.c"). The change of the parameter "find_if_needed" in the call to gnome_vfs_find_directory works around the bug in the case described: I can now delete images. But the full fix for this bug should be a little different. If .Trash-$USER does not exist, then eog should use the call to gnome_vfs_find_directory to try and create .Trash-$USER. Only if that fails (due to the user not having permissions, for example) should eog report that it cannot move the image to the trash.
Comment on attachment 63664 [details] [review] Patch to allow use of existing .Trash-$USER directory on device setting correct mime type
Thanks for the patch. I just commited it to trunk (rev.3720) The commit also adds another gnome_vfs_find_directory run to create a trash directory if needed. It's apparently intentional that you need a second call for this. Anyways... This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report. 2007-04-18 Felix Riemann <> * src/eog-window.c: (move_to_trash_real): Fix trash functionality on mounted media and automatically create a trash directory if needed. Based on patch by <>. Fixes bug 338653.
I applied the unextended patch (comment #2) to the stable branch too now.