Comment 72 for bug 688576

(In reply to David Faure from comment #7)
> Unless you can create a $topdir/.Trash/$uid (where .Trash was
> created by root), or you have a user-writable $topdir so that
> $topdir/.Trash-$uid can be autocreated, there is no other way to trash into
> the same partition. When that is the case (and yes, this is the most common
> case since mountpoints are usually not user-writable and admins don't create
> a .Trash subdir), then we have two choices:
> - trashing to $HOME, so that you can restore trashed items, as expected.
> - disabling trashing and only offering real deletion. Faster, but no going
> back.
>
> Gnome does the latter AFAIK, while I chose the former. I think it's better
> to offer a solution that doesn't lose data, even if it's a bit slower, than
> going for the fast-and-dangerous solution.
>
> I'm closing this bug; please read the trash spec for more details about
> $topdir/.Trash and $topdir/.Trash-$uid if necessary, to set one of them up
> in order to make it possible to trash on the same dir.

Reading this again and the spec it refers to (https://specifications.freedesktop.org/trash-spec/trashspec-latest.html) I am wondering what is the case currently. It might have been the case back then (when the comment was written) that the $topdir was not user-writable and $topdir/.Trash-$uid could not be created. In that case of course there would have been a problem since there would be no trash folder on the drive to trash files to. However, I read users here stating the in fact the $topdir/.Trash-$uid dir seems to have been created for them, but afterwards the files still got moved to the "root drive" trash. So I assume that at least now (don't know about the situation back then), we are actually rather facing the problem that a security check is blocking the trashing. Since the spec does not seem to talk about security or permissions in this context. So from the spec side it should be ok to change the relevant code.