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

Previous Next

Package: emacs;

Reported by: Gustavo Barros <gusbrs.2016 <at> gmail.com>

Date: Sat, 22 Oct 2022 18:24:01 UTC

Severity: normal

Found in version 28.2

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


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

From: Gustavo Barros <gusbrs.2016 <at> gmail.com>
To: Mike Kupfer <mkupfer <at> alum.berkeley.edu>
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 21:23:18 -0300
On Sun, 30 Oct 2022 at 21:01, Mike Kupfer <mkupfer <at> 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! :-)




This bug report was last modified 2 years and 182 days ago.

Previous Next


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