bug#58721: 28.2; dired with delete-by-moving-to-trash can't trash directory twice

[Gustavo Barros <gusbrs.2016@gmail.com>]

On Thu, 27 Oct 2022 at 15:20, Eli Zaretskii <eliz@gnu.org> wrote:

> We need to understand when was org-mode7AVOuq created, and why does
> Emacs tries to create it again.

Agreed.

> AFAIU from your description,
> org-mode7AVOuq was not created by the first move to trash [...]

That is correct. After the first move to trash, only "org-mode" exists
in "~/.local/share/Trash/files". Indeed, at this point there's no need
for the name to be uniquified, since there was no other directory with
the same name there before the first move to trash.

> [...] so why does
> only the second move to trash cause the error?

As far as I can tell, the existence of
"~/.local/share/Trash/files/org-mode" triggers it. I'd presume that
its existence takes the execution path to some code branch (the one
which tries to uniquify the file name/calls make-temp-file) which
tries to somehow create the directory twice.

But there's more to it. In the original report I explained why I ended
up "cloning the org repo" for this. Indeed, when creating the
reproduction recipe, I've tried first to create a simple empty file
with `touch' and a simple empty dir with `mkdir', but those did not
trigger the error. This is utterly mysterious to me. Perhaps something
like "size induced delay with some asynchronous process"? But that's
just a (very) wild guess. Truth is, I'm at a loss. And I did go
through the rabbit role to some extent, which resulted in that other
report about `move-file-to-trash', but I could not understand what's
going on here.