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


View this message in rfc822 format

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

Yet another possibility is to refrain from calling rename-file when
the moved file is a directory, and instead to do what rename-file
does, with a twist, "by hand".  That is what I actually prefer, as
nothing is really wrong with rename-file.




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.