Trash applet : no warning when a file can't be deleted

Hello,
Thank you for your bug report.
I apologize but I am a tad confused. I am unable to reproduce this issue. If a directory does not belong to me, I simply can not move it to the trash. "Unable to move to trash: Access denied". Please tell me how I could go about reproducing the problem with a short example. Also what version of Ubuntu are you running?

I'm using Ubuntu Feisty (7.04).

A few days ago, I installed Drupal (which is a CMS) for testing purposes. After my tests, I sent the folder to the trash. When emptying the trash today and seeing that it didn't delete all the files, I opened it and selected "empty trash" from Nautilus but it wouldn't work because some files couldn't be removed (that's where I discovered that I got a ignore/abort message when emptying trash with Nautilus and not with the applet menu).

After looking in the remaining files, I saw that a drupal subfolder ("css") had a locked emblem on its icon and, thinking it was just a permissions issue, discovered that its owner was in fact "nobody". I deleted it as root from a terminal.

I don't really know how you can reproduce this problem, but it seems that you can send a file that's not yours in the trash, provided that it's inside a directory that's yours.

I tried the following :
1. create a directory in my home / create a root dummy file in it / move it to the trash and empty the trash.
It worked without problem.

2. same thing but chowning the file to "nobody" (tried to change group too but the "nobody" group doesn't exist ; I don't remember what was the group of the Drupal folder that triggered the problem).
Again, it worked, trash was emptied.

3. same thing but chmodding the file to 000.
Again, trash was emptied with no problem.

I'm not able to reproduce the original problem (I'll try to reinstall Drupal when I have a bit more time). Anyway, is it normal that I can remove a file that I don't own if it's in a folder I own, just by putting it into the trash ? or maybe the file is moved in its owner's trash and not really deleted ?

Hello,
Most likely what is happening is even though the owner of the file may be not you, but you probably belong to the group that owns the file. If the group permission is set to read-write, then you will be able to modify that file including deleting it.

Unable to reproduce the bug and so is the reporter.

Why is it rejected ?
I understand it's not easy to reproduce the bug but the problem isn't the fact that undeletable files can get to the trash (this is only a trigger) : it's the difference between the way Nautilus and the Gnome applet manage the trash ; the latter doesnt display a warning dialog in case of delete issues although it should.

Hello,
I understand what you're saying, the reason it was rejected is because this issue cannot be reproduced. The nature of UNIX permissions, if the file didn't allow you to delete it, neither nautilus or gnome-trash applet would be able to remove it. The reason, I'm assuming, you were able to delete the file before was a) You were apart of the same group as that file and it the group permission was set to read-write or read-write-execute or b) The world, or all other, bit was set to read-write or read-write-execute. I am simply unable to make nautilus or gnome trash act as you described with a file or directory that I do not own or have permission to modify. If you are able to and can reproduce it, by all means please show us so this can be fixed.
Also you say that they both handle the situation differently, one gives a warning and the other does not. I am a tad confused on this because I can not even open a file with trash through nautilus or gnome trash applet. This is the reason I set the bug to rejected.

I think this bug should be reopened,
see Bug #230125 for more information.
thanks,

I've had the problem again and I can now reproduce it. It seems to come from a specific mix of root/user file access in subdirectories.
1. create a directory as simple user : mkdir testfolder1
2. inside this directory, create another one as root : sudo mkdir testfolder2
3. in that one, put a user file (you'll have to move it as root)
You then get the following structure : testfolder1 (user) -> testfolder2 (root) -> testfile1 (user)
Put testfolder1 in the trash and try to empty it from the context menu of the Gnome applet: you can't because of the folder with root access and you don't get an error message. Also, You can't move the content of the Trash elsewhere (with Nautilus), you'll have an error message related to access rights.

It seems that it's the combination of user inside root inside user directory that triggers the bug.

I can confirm this bug. I've compiled alsa from sources and I would change the path of alsa. So I delete folders of alsa and now I have alsa-lib-1.0.16rc2 in trash lol and I can't delete it. Click right button mouse on trash applet @gnome panel and pick 'Clean Trash' (in polish is "Opróżnij kosz"). The files which I haven't got permission can't be deleted, but any message doesn't inform me about it.

Note to people that are affected by the bug : you can fix the problem manually by going to ~/.local/share/Trash/files (.local is a hidden directory) and removing, as root, the problematic files.

Waiting it.

the issue is an upstream one, could you open it on bugzilla.gnome.org?

Done : http://bugzilla.gnome.org/show_bug.cgi?id=552102

Can be this bug added for Ubuntu 9.04 milestone?
This bug is too trivial, that may files from trash can't be deleted...