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

Previous Next

Full log

Message #104 received at 58721 <at> debbugs.gnu.org (full text, mbox):

From: Mike Kupfer <mkupfer <at> alum.berkeley.edu>
To: Gustavo Barros <gusbrs.2016 <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 58721 <at> debbugs.gnu.org
Subject: Re: bug#58721: 28.2;
 dired with delete-by-moving-to-trash can't trash directory twice
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.

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.