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

[Gustavo Barros]

On Fri, 28 Oct 2022 at 13:06, Gustavo Barros <gusbrs.2016@gmail.com> wrote:

> > I get the same result.  But I think this is expected, as the
> > `rename-file' docstring says:
> >
> >     For NEWNAME to be recognized as a directory name, it should
> >     end in a slash.
> >
> > So this function seems to be working as documented.

> That is, no end slash appended to the directory at
> `move-file-to-trash'. So, it appears we have a good suspect. Why it
> works when the filesystem is the same still beats me.

Uhm, it is still not this. The previous sentence in the docstring you
(Stefan) mentioned is:

    If NEWNAME is a directory name, rename FILE to a like-named file under
    NEWNAME.  For NEWNAME to be recognized as a directory name, it should
    end in a slash.

And, indeed, if we do:

    (rename-file "/path/to/orig/barbaz" "/path/to/dest/barbaz-foobar/" t)

the operation succeeds, but the result is:

    /path/to/dest/barbaz-foobar/barbaz/zero.file

And that's not what we want, or not what `move-file-to-trash' is
trying to do. And that is precisely why it is passing the
`ok-if-already-exists' as `t' there in the first place.

In other words, as far as I can see, the sentence:

    For NEWNAME to be recognized as a directory name, it should
    end in a slash.

should not imply that if `ok-if-already-exists' is `t' `rename-file'
should fail to overwrite, whether the `newname' is a directory or not.