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

[Mike Kupfer <mkupfer@alum.berkeley.edu>]

Gustavo Barros wrote:

> I may be wrong but, as far as my reading goes, I think this might
> misbehave if the "directory" is a symlink. `is-directory' is built as
> `(file-directory-p fn)' which returns t even if it is a symlink to a
> directory. 

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.

> Besides that, in general, imho I cannot think of this issue as
> something else other than a misbehavior of `rename-file', so that the
> patch in these terms feels like a workaround.

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'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.

mike