GNU bug report logs - #27986
26.0.50; `rename-file' can rename files without confirmation

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: rms <at> gnu.org, johnw <at> gnu.org, p.stephani2 <at> gmail.com, michael.albinus <at> gmx.de,
 monnier <at> IRO.UMontreal.CA, 27986 <at> debbugs.gnu.org
Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without
 confirmation
Date: Mon, 11 Sep 2017 20:09:48 +0300

> Cc: monnier <at> IRO.UMontreal.CA, johnw <at> gnu.org, rms <at> gnu.org,
>  p.stephani2 <at> gmail.com, 27986 <at> debbugs.gnu.org, michael.albinus <at> gmx.de
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Mon, 11 Sep 2017 09:45:48 -0700
> 
> On 09/11/2017 07:47 AM, Eli Zaretskii wrote:
> > do these changes modify interactive
> > behavior in incompatible ways?  I thought we agreed to leave the
> > interactive behavior intact, and only change the non-interactive uses.
> >
> That wasn't my understanding. In our last email exchange about 
> interactivity I proposed that Emacs prompt the user when the destination 
> is not a directory name but happens to be a directory (see 
> Bug#27986#97), but you were dubious about that (Bug#27986#100) so I left 
> it alone.
> 
> I normally use dired to rename files in Emacs, and dired's behavior 
> hasn't changed as far as I can tell. Where there is a bit of a change is 
> when using M-x rename-file directly. Here, in the typical case with file 
> name completion there is still no difference, since names of destination 
> directories are completed to have trailing /. However, if one uses "M-x 
> rename-file foo RET and then laboriously types out the name of an 
> existing directory /tmp/destination-dir without using completion and 
> without trailing / before hitting RET, one will notice a difference: 
> rename-file will now say "File /tmp/destination-dir already exists; 
> rename to it anyway? (yes or no)" and if one types "yes" the rename will 
> typically fail. So yes, this is a (noisy) incompatibility with previous 
> usage. If you like I can go back and implement the suggestion in 
> Bug#27986#97; this would be more-compatible with existing usage. I 
> suggest leaving it alone, though, as things are simpler and easier to 
> explain the way they are.

I think there was a confusion here between interactive and
non-interactive uses of rename-file.  For interactive use, AFAIR we
agreed that the behavior should stay as before, in particular to be
consistent with e.g. invocation of 'mv' from the shell prompt.

For non-interactive use, we agreed to change the behavior wrt
directories, with a slight preference to signaling an error even if
the target is an empty directory.

Previous Next

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