Version: (using KDE 4.0.5) Installed from: Fedora RPMs I had some large files in ~/.local/share/Trash/files/ but trash in Dolphin "claimed" to be empty. Even "Empty trash" did not try to clean all that (for some reason) left in the trash and "orphaned" (no meta-data for the files or so?!?). As the same user I was able to remove the files from trash manually - so these were no user-right-problems (like described in another ticket I found).
@Stefan: Is this issue still reproducible in KDE 4.1.x/trunk? I could not reproduce it and also did not get similar bug reports, so I'm quite sure this issue has been fixed already... Thanks!
Yes this bug still exists, I haven't had time to add this logic to kio_trash yet.
OK, I still wonder how this can happen. To summarize, there are various cases that can create trouble: - readonly files and directories are chmod'ed before deletion so that the deletion works, since that Sept-2006 fix (bug 116371, bug 130870). - non-empty root-owned directories cannot be deleted by the user, so for these kio_trash keeps the trashinfo file, so that root can delete the stuff later on (also part of bug 116371) - I'm about to add code (to kde-4.2) that deletes orphaned files (files without a .trashinfo), to improve the chances of "empty trash" really emptying the trash." I noticed that as a side-effect, root-owned (and 0600, i.e. unreadable) .trashinfo files mentionning root-owned trashed files will be leftover even after the trashed file itself is cleaned up (since we can't read the trashinfo file and associate it with the trashed file)... so in general it will be possible to delete other user's files from your trash. Oh well, they're supposed to use their own trash anyway ;) (this mixup can really only happen with su / sudo). This patch will fix this bug, but what I'm really missing is a clear description of how one can end up in the situation where there are user-owned leftover files in ~/.local/share/Trash/files/. One possibility would be a race between two instances of kio_trash, i.e. it would only happen when a long trashing operation is happening and you have time to trigger a second one at the same time...
SVN commit 901238 by dfaure: Clean up orphaned files from ~/.local/share/Trash/files when doing "empty trash". BUG: 167051 M +10 -0 tests/testtrash.cpp M +31 -3 trashimpl.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=901238
I'm still seeing this error in hardy. Here's is what I do to empty the trashcan. I find something to delete and then I'm able to empty the trash. I also manually remove the /.local/share/Trash manually from time to time.