bug#28792: 26.0.60; Deleting to a custom trash directory in Dired gives error

[Eli Zaretskii]

> From: Göktuğ Kayaalp <self@gkayaalp.com>
> Date: Thu, 12 Oct 2017 15:50:26 +0300
> Cc: Paul Eggert <eggert@cs.ucla.edu>, 28792@debbugs.gnu.org
> 
> Quite recently I've opened and retreated the similar bug#28791, trying
> to trash directories recursively.  I did not use a custom
> trash-directory, but I got the same error.  Turns out that it was
> delete-by-moving-to-trash that provoked the error (with an indentical
> message to yours).  Emptying the ~/.local/share/Trash/ folder solved the
> issue for me.  I observed that in ~/.local/share/Trash/info/ some
> .trashinfo files were created with the name of the directory (say
> <dirname>) I was trying to delete, one <dirname>.trashinfo and many
> <dirname><random bits>.trashinfo.

This use case raises an interesting question: what should be the
behavior of delete-by-moving-to-trash when the Trash directory already
includes a directory by the same name as the non-directory file being
deleted?  Are files in the Trash directory generally unimportant
enough to disregard these situations, or does this use case run afoul
of the ability to restore the trashed files later?

I don't know the answers, as I intentionally avoid using the system
trash.