GNOME Bugzilla – Bug 614955
Delete does not work on ntfs
Last modified: 2012-11-20 21:39:54 UTC
In Ubuntu Karmic arQon reported: eog in current 9.10 does neither. file on ntfs partition cannot be moved to trash in eog, and can't be deleted outright because eog is also ignoring the preferences specified in nautilus to allow real deletes, and has no such option of its own. file is 777, and can be rm'd from a terminal. *nautilus* exhibits the (correct) behavior of 192629. eog is simply broken. > "Error on deleting image <foo bar.tga>" > "Couldn't access trash." as an aside, eog also whines for confirmation of "move to TRASH", which is about as redundant and user-time-wasteful as you can get. how many prompts do you need for a RECOVERABLE action? Launchpad ref: https://bugs.edge.launchpad.net/ubuntu/+source/eog/+bug/526925 Thanks!
(In reply to comment #0) > In Ubuntu Karmic arQon reported: > > eog in current 9.10 does neither. file on ntfs partition cannot be moved to > trash in eog, and can't be deleted outright because eog is also ignoring the > preferences specified in nautilus to allow real deletes, and has no such option > of its own. > > file is 777, and can be rm'd from a terminal. *nautilus* exhibits the (correct) > behavior of 192629. eog is simply broken. > > > "Error on deleting image <foo bar.tga>" > > "Couldn't access trash." > Okay, this is strange. The image is marked as "can-trash" by GIO, so instead of asking for deletion (which eog in fact supports), eog asks for (and tries to) trashing. Hmm, I'll need to check the exact error why trashing fails to actually create the trash in this case. Regarding the nautilus setting. Well, I wasn't a fan of cross-application GConf-settings as they don't guarantee that nautilus is actually running and enforcing this policy, but I can rethink it if you want. > as an aside, eog also whines for confirmation of "move to TRASH", which is > about as redundant and user-time-wasteful as you can get. how many prompts do > you need for a RECOVERABLE action? The message box is only shown when you use the Del key to avoid accidential trashing without noticing, if you use it from the menu (and likely from the toolbar as well) it wont bother you. Then it can be set to not ask again for the remaining session by checking the corresponding box when the dialog first shows up. But if it's really bothering you can disable it by setting the "/apps/eog/ui/disable_trash_confirmation" GConf setting.
Created attachment 169602 [details] gdb backtrace Any news on this? :) I'm using eog 2.31.91-0ubuntu1 (current development version of Ubuntu) and other than you I'm not seeing the image marked as "can-trash" (see backtrace).
(In reply to comment #2) > Created an attachment (id=169602) [details] > gdb backtrace > > Any news on this? :) Nothing yet, sorry. Haven't really had the time to dig deeper into this yet. > I'm using eog 2.31.91-0ubuntu1 (current development version of Ubuntu) and > other than you I'm not seeing the image marked as "can-trash" (see backtrace). If I'm parsing your backtrace correctly you are one "next" short of having can-trash set. ;)
> If I'm parsing your backtrace correctly you are one "next" > short of having can-trash set. ;) Oops, debugging fail. :)
Okay, I took another look at this. What happens when trashing is that GVFS tries to create the per-user trash folder (.Trash-$uid) on the NTFS partition. Apparently though NTFS3g doesn't work with NTFS-ACLs and thus the trash folder will be owned by the user who mounted the volume (in my case root). Now GIO checks if the owner of the created trash folder equals the user which the folder now fails. The problem is that when GIO falls back to use/create a per-user trash folder (.Trash-$uid; because a global .Trash is not available on the volume) it checks if the folder is actually owned by the user. On mounted NTFS volumes this is apparently not the case and thus GIO aborts the trash operation. I'll see if we can workaround this e.g by falling back to a normal delete in case trashing doesn't work.
Hmm, why did I write the same explanation twice?
*** Bug 668208 has been marked as a duplicate of this bug. ***
This bug was reported against a version which is not supported any more. Developers are no longer working on this version so there will not be any bug fixes for it. Can you please check again if the issue you reported here still happens in a recent version of GNOME and update this report by adding a comment and adjusting the 'Version' field? Again thank you for reporting this and sorry that it could not be fixed for the version you originally used here. Without feedback this report will be closed as INCOMPLETE after 6 weeks.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!