eog won't delete images on different volume

[mannheim]

If you are viewing an image with eog and ask eog to delete the image (move to trash), then eog will fail to do so unless the image file resides on the same volume as /home/user. Instead, it just puts up a dialog box saying it failed to delete the image.

What eog should do is what Nautilus does:

(1) Move the file to ~/.Trash if the file lies on the same volume as ~/.

(2) Move the file to /mountpoint/.Trash-$USER if the volume is mounted at /mountpoint and .Trash-$USER exists.

(3) If /mountpoint/.Trash-$USER does not exist and user has rwx permissions for /mounpoint/., then create /mountpoint/.Trash-$USER and do step (2).

gthumb does (1) and (2) but not (3), while eog does only (1).

The result is that the basic supplied applications in ubuntu/dapper for viewing and organizing images are both unable to delete images in a very common situation (e.g. when a user has a bunch of imags on a USB memory stick).

I filed bug's in gnome's bugzilla a while ago, on both eog and gthumb. Because these have not yet been triaged, and because dapper's release is not far off, I am entering these bugs here. (I hope this is not bad procedure.) In my eog bug report on bugzilla, I also pointed out a one-line change in the source which would fix eog so that it at least does (2). The corresponding line of code in gthumb *looks* like it should do (3) also (according to the documentation of gnome-vfs), but fails to do (3).

It may be that the failure to do (3) is not a bug in eog or gthumb. But the failure of eog to do (2) certainly is.

The relevant bugzilla.gnome bugs are:

http://bugzilla.gnome.org/show_bug.cgi?id=338653
http://bugzilla.gnome.org/show_bug.cgi?id=339180

[Tim Butler (timbutler)]

This is an example of the error produced by eog for this bug.

[Sebastien Bacher (seb128)]

Thank you for your bug and the upstream pointer

[Edward Clark (eeclark)]

It has been almost a year and this bug still exists.

[Sebastien Bacher (seb128)]

bug fixed upstream now

[Sebastien Bacher (seb128)]

This upload fixes the bug:

 eog (2.19.1-0ubuntu1) gutsy; urgency=low
 .
   * New upstream version:
     - Complete rewrite of application core which means more stable,
       maintanable, faster image viewer for GNOME
     - Editable application toolbar
     - New image collection pane with on-demand thumbnail loading
       (Ubuntu: #37429)
     - Support for setting image collection position (left, right, top,
       bottom) and wether it's resizable or not. No preference UI yet
     - New image properties dialog which replaces the image info sidepane
     - Single instance D-Bus-based activation support
     - Revamped error/warning UI
     - "Open with" support to quickly open images on other applications
     - Mouse scrollwheel improvements: HIG compliancy and zoom factor setting
     - Migration to GtkRecent
     - UI polishing on multiple images save as dialog
     - Command line options for fullscreen, slideshow and image collection
       disabling
     - Rotate work in fullscreen (Ubuntu: #31783)
     - Don't crash when cancelling a slideshow load (Ubuntu: #43322)
     - Trash work on different volume (Ubuntu: #42571)
     - Display the correct window icon (Ubuntu: #43609)
     - Don't write wrong rotation information (Ubuntu: #88248)
     - Enhanced shortcuts work (Ubuntu: #44343)
     Bug fixes:
     - #377123, [eog-ng] implement EogJobSave
     - #319859, "open image with" function
     - #334321, Should be possible move the collection in EOG
     - #316175, EOG gives no error upon opening non image files
     - #432439, Run gtk-update-icon-cache in uninstall-hook
     - #429156, [patch] "Save As" dialog for multiple files is way too ugly
     - #427154, Some strings are not translated in save-as-multiple dialog.
     - #419756, Slideshow background should be black.
     - #404708, eog crashed with SIGSEGV in g_closure_invoke()
     - #404126, Convert debug messages to eog_debug_message
     - #401939, [eog-ng] Remove leaftag support.
     - #399333, EOG-NG crash while opening Print dialog
     - #398250, build bug: missing symbols from libpangoft2
     - #389314, eog should use stock_print-setup from g-i-t for the
                "Page setup..." action
     - #376513, TRACKER: command-line options
     - #355858, switching image forward and back quickly can display wrong image
     - #351040, [eog-ng] use GtkRecent
     - #344140, [eog-ng] remove duplicate code in fullscreen-code
     - #342817, crash trying to view profile image
     - #342103, [patch] [eog-ng] update about dialog
     - #341935, Should not zoom with mouse wheel
     - #341831, [eog-ng] memory usage increases when switching fastly between
                images
     - #341600, [eog-ng] EOG eats a lot o CPU when inactive
     - #340957, Filenames containing numbers are not properly sorted (as how
                nautilus does)
     - #335689, Middle mouse drag should also scroll
     - #327424, progress bar changes view size which forces re-zooming of image
     - #322057, eog print output is corrupt
     - #305823, The rotate buttons on the toolbar are blurred
     - #404907, [eog-ng] Crash when openi...

[Michalxo (michalxo)]

Same bug still persist in Version: 2.22.1-0ubuntu2 on hardy

[Andrew Simpson (adpsimpson-gmail)]

To back up Michal T - this bug is still present in the latest version of Ubuntu. This effectively means that the default image viewer shipped with Ubuntu isn't able to handle the most common of tasks and, in many cases, isn't really usable.

If the bug was fixed in 2.19.1 in Gutsy, it has since re surfaced. I'd suggest this is high priority.

[mannheim (kronheim)]

To clarify this: I think eog is doing all it can. Since the original bug report, the name of the trash file has changed in recent gnome. But this is what eog does, I think, assuming that the images to be deleted are on a different volume than /home and that the users uid is 1000:

(A) If the trash directory .Trash-1000 exists at the top level of the volume, move the image to .Trash-1000
(B) If the trash directory .Trash-1000 does not exist at the top level of the volume, try and create it.
(C) If the user does not have permission to create it, then fail.

Nautilus does essentially the same thing. The between eog and nautilus is that, if failure occurs, nautilus will offer to "delete the file immediatley" (instead of moving to trash). Perhaps eog should do the same. Apart from this detail, my guess is that there is no fix for this: it's just how the trash works in gnome (but I'm not an expert).

[Wouter Stomp (wouterstomp-deactivatedaccount)]

Reopening, as in intrepid it is still not possible to delete them. Eog should offer to delete them if moving to trash is not possible.

[Sebastien Bacher (seb128)]

don't reopen closed bugs because a new version has a similar issue, eog uses gio now and the code issue is likely a different one and could be a gio bug

[Andrew Simpson (adpsimpson-gmail)]

"eog uses gio now and the code issue is likely a different one and could be a gio bug"

This is not a useful response. As an end user, this functionality is broken, and has always been broken. I don't know or really care what gio is. Whichever library the problem is in, it is still a bug which I see in eog, and only in eog. If the underlying reason for the bug has changed, that's fine. But the bug still remains, so saying it is fixed is inappropriate and untrue.

[Sebastien Bacher (seb128)]

the bug tracker is not an user forum to discuss issues, it's a tools to describe issues that needs to be fixed, the new version of the software can have a similar issue but it doesn't means that's the same bug, could you open a new bug rather than commenting on a bug closed for a year which is going to create confusion?

[Tony Sam (samant-ua)]

I use eog version 2.24.1, but else have an error with deleting picture in a mounted volume. Can you do to delete picture at all or to the /home/username/.Trash folder?

[Colin (drcsturm)]

I can not delete image from an NTFS drive.
Another option would be to hold down shift delete which would bypass the trash bin and permanently delete the image.

[Petro (pporchuk)]

I have same issue (lucid 10.04).
EOG throws same exception

Error on deleting image Hotyn_KP 161.jpg
Couldn't access trash.

Shift+del doesn't work for me.

[Joni Nevalainen (joni-nevalainen)]

Ran across the issue in lucid 10.04. Could not delete a picture from a different partition in the same harddrive (NTFS-formatted). The drive is mounted so that my user account has read/write access to it.

Workaround: Made a .Trash-1000 folder manually to the partition root directory (my UID is 1000). Now the error message changed to a warning message, but I could delete the picture. The warning message is: "A wastebasket for (IMGNAME) couldn't be found. Do you want to remove this image permanently?"

The bug could still use patching, since by the original error messages "Are you sure you want to move (IMGNAME) to the Deleted Items folder?" and "Error on deleting image (IMGNAME) - Couldn't access Deleted Items folder." aren't too informative in creating the workaround folder to say, an external SD-stick while browsing newly taken pictures.

[Scott Murray (scott-g-murray)]

this is an extremely annoying bug. Still occurring on 11.04! My home partition is running low so I moved my ~/Photos folder
to another partition and created a link from ~/Photos to the new location on the other partition. Now this bug hits me.

[Michael Rose (michael-q-rose)]

Five years later and the bug is still there. Hell, can someone please fix it?

[cthulhu1987 (boris-baran)]

How in the name of the Flying Spaghetti Monster is the big STILL THERE after TEN YEARS??

[iBART (mogio)]

Still here... :o

[Amedee Van Gasse (amedee)]

Bug still exists in 2022.
Observed on an ext4fs that is mounted over smb.