Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation

From: Eli Zaretskii <[email-masked]>
Date: Mon, 14 Aug 2017 18:34:30 +0300

> From: Paul Eggert <[email-masked]>
> Cc: Eli Zaretskii <[email-masked]>, [email-masked]
> Date: Sun, 13 Aug 2017 16:48:59 -0700
> 
> Getting back to Philipp's original bug report, Apple documentation says macOS 
> has a facility like the Linux renameat2 system call (i.e., it's like 'renameat' 
> except it can be told to fail if the destination already exists). Attached is a 
> proposed patch to use this facility, which means that the case-insensitivity 
> test would no longer need to be done in macOS. If there's some way to implement 
> renameat_noreplace on MS-Windows we could get rid of the case-insensitivity test 
> there too.

There's nothing easier than implementing renameat_noreplace on
MS-Windows, since the underlying system call does that by default, and
it's emulating the Posix behavior that requires complications.  In
fact, we already have this implementation: see sys_rename_replace (in
w32.c) which needs to be called with its last argument FALSE (modulo
the "at" part, which is easily handled).

(Ken, what about Cygwin?)

So I think we may be able to remove the case-sensitivity check right
now.  And in any case, that check should be in
barf_or_query_if_file_exists anyway, because renameat_noreplace on
case-insensitive filesystems already supports renaming to a different
letter-case.  The reason we had this check before is because we didn't
employ renameat_noreplace, but called 'rename' right away, and that
needed a question before overwriting the target.  But now
renameat_noreplace will silently succeed to rename when the user wants
to only change the letter-case, so no such check is needed.