From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani
> From: Philipp <p.stephani2@gmail.com>
> Date: Sun, 06 Aug 2017 17:40:18 +0200
>
> (rename-file "/tmp/emacs/=E1=BA=9E" "/tmp/emacs/=C3=9F&= quot;)
> nil
>
> Note how `rename-file' has silently overwritten `=C3=9F'.=C2= =A0 This is because on
> macOS, `=C3=9F' and `=E1=BA=9E' are different file names, but = Emacs treats them as
> equal.=C2=A0 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?=C2=A0 If the latter, please elaborate.=C2=A0As this example shows, there are cases where two case= -insensitive filenames are considered equivalent by Emacs, but different by= the actual filesystem. This is unavoidable, because the definition of &quo= t;case-insensitive" changes all the time, both in Emacs and in the fil= esystems. Generally it's impossible to detect whether two filenames wou= ld refer to the same file without actually creating the file. And even then= the answer depends on how the file is created, see e.g. FILE_FLAG_POSIX_SE= MANTICS. So Emacs can't compare filenames and make decisions based on t= he result upon which the correctness of a critical function depends. Compar= ing filenames can still be OK for best-effort attempts at giving the user b= etter error messages or similar.=C2=A0If the former,
then at least on MS-Windows we have a race anyway, because the
underlying system APIs are not atomic.Woul= dn't MoveFileExW with MOVE_FILE_REPLACE_EXISTING be atomic?<= br>> and `rename-file' should use link(2) + unlink(2) if renameat2
> isn't available.
'link' and 'unlink' accept strings as arguments, not intege= r numbers
such as 2.Yes, I mean the functions de= scribed in section 2 of the man page. link(2) is a common markup for this.<= /div>--001a1143b6f2ca0ca40556b9ba63--=C2=A0
More to the point, how can this strategy work on a case-insensitive
filesystem?=C2=A0 What am I missing?II= UC link(2) + unlink(2) would, if successful, guarantee enough atomicity in = the sense that the old file is now guaranteed to be the new file, and the c= all is guaranteed to fail if the new file already exists. I don't think= anything can help with the case-changing problem; I think we just have to = live with an occasional false positive signal in this case.=C2=A0