Emptying trash should really empty trash

Thanks for your bug. Do you have an example of when it happens? What do you do exactly to get this?

This came out of EvaluateUbuntuGuide, which mentioned that you can use sudo to forceable empty your trash. It is a general thing I have actually only really seen on my GF's OS X laptop, but I have had permissions change generally.

I guess what I am really saying is that this is a preemtive bug report for a possibly use case.

I have an example (though I can't give exact details because that computer is not here). It's not about permissions changing while already in trash, but close enough:

I built Epiphany and Epiphany-extensions manually, the "sudo checkinstall":ed them. Afterwards, I deleted the source directories, but when I tried to empty the trash, I couldn't due to permission problems.

Either I shouldn't be able to move something to trash if I haven't the permissions for it, or a gksudo question should pop up to confirm that I really want to do this. I personally prefer the second solution, it's much easier to solve the problem that way than finding and changing permissions on files before moving to trash.

I've got one, in fact it's stuck in the trash until I feel like using terminal or nautilus with sudo.

I had built and app and then installed it with checkinstall.
I deleted the folder after I downloaded a new source version, but the doc-pak subfolder will not allow the app folder to be deleted (after it's in trash.)

I also think being prompted with a password if there are files without user permissions in the trash is a good idea...

Do you have an example to describe for that?

Ok, this has just happened to me again. I have file named "lock" which is a broken symbolic link to `127.0.0.1:5771'. Trying to delete it crashes nautilus, as does view the properties.

Corey, your issue is a different one and known as http://bugzilla.gnome.org/show_bug.cgi?id=323016 upstream

I think this bug can be reproduced in the following way (using Nautilus 2.12.1 at least):
Create a folder foo with a subfolder bar, and give no rights to the normal user for the folder bar. The user can move foo to the trash, but if he tries to delete it, he gets the (slightly misleading) error message: " "foo" cannot be deleted because you do not have permissions to modify its parent folder."

More concrete:
$ mkdir foo
$ cd foo
$ sudo mkdir bar
$ sudo chmod 600 bar

Then use Nautilus to move foo to the trash, then try to empty the trash.

Following Marcel's steps with a fully updated Dapper Flight 5 reproduces the error. The trash (Wastebasket) is not emptied and gives no error.

This is quite strange, because it would let a user to remove a file which he/she has no rights on. This can easily render a system unusable, as you can just let a important directory to be removed incorrectly.

I agree with Corey about this bug. In my ~/src/ I do my coding stuff, and if some files are owned by root (like after sudo make stuff), you can move them (like in the trash or anywhere), but you cannot delete them. Pretty irritating :)

Even worse: nautilus is so not helping telling you what file has wrong permissions (see screenshot).

Even Even Worse: Missing "skip all" button, so you have no change when you have 100s of files there ;( (on the screenshot too)

well, at least there is a cancel :)

Yes, missing "skip all" is a terrible thing. You can have root files in the trash if you use nautilus as root and trash some file from there.

I get annoyed by it too... it wouldn't be hard to have it find those files and if they are they prompt for a password and then delete them.
Otherwise have the trash tell that you can't move them there because the trash is not supposed to take them. But that would be dumb.

This "bug" is still here... another example, which is actually quite common scenario for me.

I create some files and directories, say it's /var/www/cake . Many web apps require a directory that's writable by a web server. In this case, it's /var/www/cake/app/tmp . Files created by apache belong to www-data:www-data . You can move /var/www/cake to trash, but then you can't erase /var/www/cake/app/tmp from it.

Now... if a user didn't have root privs, then he'd be stuck with a non-empty trash forever.