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

[Eli Zaretskii <eliz@gnu.org>]

> From: Mike Kupfer <mkupfer@alum.berkeley.edu>
> cc: Eli Zaretskii <eliz@gnu.org>, 58721@debbugs.gnu.org
> Date: Sun, 30 Oct 2022 17:01:41 -0700
> 
> 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.

What is the expected semantics of moving a symlink to trashcan?  Is it
supposed to move the symlink or its target?  (I'd think it's the
former, but maybe my instincts are wrong.)  If the expectations are
that the symlink is moved, then all we need to do is to treat symlinks
as regular files, by augmenting file-directory-p not to dupe us.

> > 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'm okay with filing another bug report about rename-file, and
discussing this there.  But that's a separate issue, and fix of this
bug should not depend on that.