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

[Gustavo Barros]

On Sun, 30 Oct 2022 at 21:01, Mike Kupfer <mkupfer@alum.berkeley.edu> wrote:

> Good point, thanks.  I think this points out a pre-existing issue with
> move-file-to-trash, in that the code to create a unique trash name will
> create a directory, rather than a file.

I agree, I also think that there was a pre-existing inconsistency
there, but `rename-file` would cover it up later on. But trying to do
it manually, complicates things in this regard as well.

> I agree that it's an inconsistency in the behavior of rename-file.  If
> the thing being renamed is a file, the target gets replaced, whether or
> not we're crossing filesystems.  But if it's a directory, the target
> gets replaced if it's in the same filesystem, but it's an error if the
> target is in a different filesystem.  If I understand Eli's concern,
> it's a question of whether making the behavior more consistent is worth
> the risk that it would break existing code--code that could assume the
> current behavior.

I understand that concern too. But we don't even understand well (as
far as I can see) why it fails when crossing filesystems, and are
already rushing to a workaround. I just offered some respectful
resistance. And if, after all, the decision is not to touch
`rename-file' because it's risky, so that a workaround is really what
is intended, I'll get that.

> I'd like to resolve the symlink behavior before pushing any fix.  But
> I've been feeling increasingly unwell as the day has progressed, so I
> think I'll stop work on this bug until I'm feeling better.

Get well soon! :-)