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

Previous Next

Full log

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

From: Mike Kupfer <mkupfer <at> alum.berkeley.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58721 <at> debbugs.gnu.org, gusbrs.2016 <at> gmail.com
Subject: Re: bug#58721: 28.2;
 dired with delete-by-moving-to-trash can't trash directory twice
Date: Sat, 29 Oct 2022 09:32:52 -0700

Eli Zaretskii wrote:

> > From: Mike Kupfer <mkupfer <at> alum.berkeley.edu>
> > Date: Sat, 29 Oct 2022 08:24:53 -0700
> > 
> > I played with this some more this morning, this time on Emacs 29.  It
> > looks like rename-file should have called copy-directory as
> > 
> > copy-directory("/tmp/emacs-git"
> >   "/home/kupfer/.local/share/Trash/files/emacs-gitH0lx1e/" t nil t)
> 
> I don't think we can change how rename-file behaves when the argument
> is a directory.  Any changes we need to make must be in
> move-file-to-trash, not in primitives it calls.

Yes, that makes sense.

So... (rename-file "a" "/tmp/newa" t) gives the original error.

(rename-file "a" "/tmp/newa/" t) gives us /tmp/newa/a/b.

What we want is /tmp/newa/b.

I can think of 2 ways forward.  One is to add an optional argument to
rename-file to get the desired behavior, like the copy-contents argument
to copy-directory.

The other is for move-file-to-trash to call rename-file on the top-level
contents of the directory that is being trashed ("a/b" in my simple test
case), rather than on the directory itself.

I think the first approach is preferable, in that it parallels the
definition of copy-directory.  But either should work.

mike

Previous Next

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