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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp <p.stephani2 <at> gmail.com>
Cc: 27986 <at> debbugs.gnu.org
Subject: Re: bug#27986: 26.0.50;
 `rename-file' can rename files without confirmation
Date: Sun, 06 Aug 2017 20:05:09 +0300

> From: Philipp <p.stephani2 <at> gmail.com>
> Date: Sun, 06 Aug 2017 17:40:18 +0200
> 
> (rename-file "/tmp/emacs/ẞ" "/tmp/emacs/ß")
> nil
> 
> Note how `rename-file' has silently overwritten `ß'.  This is because on
> macOS, `ß' and `ẞ' are different file names, but Emacs treats them as
> equal.  Probably the test for case-insensitive file names should be
> removed altogether

Which one? there are two of them.

> (it can't work correctly and introduces a filesystem race)

It cannot work correctly _because_ of a possible race or because of
some other reasons?  If the latter, please elaborate.  If the former,
then at least on MS-Windows we have a race anyway, because the
underlying system APIs are not atomic.  So at least on MS-Windows the
feature should stay, as it introduces no new issues and supports a
valid and quite important use case (the Windows shell supports it as
well, so we really cannot do less).

> and `rename-file' should use link(2) + unlink(2) if renameat2
> isn't available.

'link' and 'unlink' accept strings as arguments, not integer numbers
such as 2.

More to the point, how can this strategy work on a case-insensitive
filesystem?  What am I missing?

Previous Next

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