From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation Date: Mon, 14 Aug 2017 16:50:33 +0000 Message-ID: References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> <0e80a1cf-8217-9e9a-a00f-9fdbd6575fc4@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a1143b6f2ac424f0556b97618" X-Trace: blaine.gmane.org 1502729520 977 195.159.176.226 (14 Aug 2017 16:52:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 14 Aug 2017 16:52:00 +0000 (UTC) Cc: 27986@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Aug 14 18:51:56 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhIaj-00087P-RF for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Aug 2017 18:51:50 +0200 Original-Received: from localhost ([::1]:34268 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dhIaq-0002Fi-2m for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Aug 2017 12:51:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39743) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dhIa2-0001dJ-Sp for bug-gnu-emacs@gnu.org; Mon, 14 Aug 2017 12:51:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dhIZy-0001tY-Rx for bug-gnu-emacs@gnu.org; Mon, 14 Aug 2017 12:51:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:55435) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dhIZy-0001tH-Oh for bug-gnu-emacs@gnu.org; Mon, 14 Aug 2017 12:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dhIZy-0005DH-GO for bug-gnu-emacs@gnu.org; Mon, 14 Aug 2017 12:51:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Aug 2017 16:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27986 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 27986-submit@debbugs.gnu.org id=B27986.150272945020033 (code B ref 27986); Mon, 14 Aug 2017 16:51:02 +0000 Original-Received: (at 27986) by debbugs.gnu.org; 14 Aug 2017 16:50:50 +0000 Original-Received: from localhost ([127.0.0.1]:35883 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhIZm-0005D3-7V for submit@debbugs.gnu.org; Mon, 14 Aug 2017 12:50:50 -0400 Original-Received: from mail-oi0-f53.google.com ([209.85.218.53]:33067) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhIZl-0005Cx-DK for 27986@debbugs.gnu.org; Mon, 14 Aug 2017 12:50:49 -0400 Original-Received: by mail-oi0-f53.google.com with SMTP id f11so89248731oic.0 for <27986@debbugs.gnu.org>; Mon, 14 Aug 2017 09:50:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lmiz5aayluSWdeK1TsC5EY0RfTzp1qWkOWbuCyLepzs=; b=qG+bAFVA2JcF+luQ3zB5K4nC+68/kmJUd8LKKpHCSExyy1PzcKQN8/10DHLN9vAm+C a7cvobvinfis7+kv6wXn5dbXj3k/21a8fIDN1/7cP30coOivZt+5AbELdjq/seLmA08/ RoadN2IE1Vxkf22dzanz0UPGI335BT7/HCoDdpTLyQzeKecbcPRbk756xg+lNAkTYHiX uOzvpSQaHXECeek9VBzqE1JEyPFjwvLGgQcaFVWLB2+t+P4KlxIvVd5LqK7ZEfdeCcaf 2rkrND4ERNyu6fGFv9HzHS7E8QTgY6sZskvGAik6kcuu2TRndWXTJrcm9TOeqFSiOBP/ 6zZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lmiz5aayluSWdeK1TsC5EY0RfTzp1qWkOWbuCyLepzs=; b=t1+jHHd9k46FMuJqfmqckD/GeOQvrb6BEFVx4DQ9AvxNXH7p6B5s4UGkdR0L4H63Q6 mEWaHScR9zoThJX7Rek1gCw7D7V+E9BNmT6cL5qJDncq2neQZAtQEcBwjl9M4cvdEIK+ SbbZCtbZCEMJqgmmL4CQi0XqC5LKC9PYEvtjz4Kt/BIbNGn3oqqMgjR6SunspjvCdElb 327e+fWG68Py0FTxtptrlnvMd/c98sXKQ2iX63UgRW/1pSe/MmPx19Dpn/nvPxPQMBQi P1sKoBwsu9xoCQxQoqEhnpCs8ixDOpPvJQ7b/8TYT+GYpXCxlU+LG417U7kkGs7DAt9m CDzA== X-Gm-Message-State: AHYfb5gyfrSJeJFZoSRNdGSbIjSv7432lj1zt3Tcp/hZKgy2N8o1pSrX ZSHt1UeYUO23Y9ufIAwkClIXEjEWnA== X-Received: by 10.202.208.144 with SMTP id j16mr30291943oiy.82.1502729443491; Mon, 14 Aug 2017 09:50:43 -0700 (PDT) In-Reply-To: <0e80a1cf-8217-9e9a-a00f-9fdbd6575fc4@cs.ucla.edu> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:135750 Archived-At: --001a1143b6f2ac424f0556b97618 Content-Type: text/plain; charset="UTF-8" Paul Eggert schrieb am Mo., 14. Aug. 2017 um 01:49 Uhr: > 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. > > I don't have easy access to macOS so I have not installed this patch. It'd > be > nice, Philipp, if you could try it out. > > Thanks, the patch fixes the problem. However, it's still not 100% correct: now casing changes such as from "A" to "a" where macOS treats the file names as equivalent trigger the "file already exists" signal as well. I don't think that can be fixed, though; there's no way to special-case casing changes while keeping atomicity intact. So I'd rather have Emacs react conservatively and skip the casing check entirely. Note that the manpage says: RENAME_EXCL On file systems that support it (see getattrlist(2) VOL_CAP_INT_RENAME_EXCL), it will cause EEXIST to be returned if the destination already exists. I interpret this such that if the filesystem doesn't support RENAME_EXCL the rename will succeed even if the destination exists. Since we probably won't be able to solve all issues across operating systems and filesystems, probably we should have at least a warning in the documentation that rename-file attempts to be race-free and atomic, but only on a best-effort basis. --001a1143b6f2ac424f0556b97618 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Paul E= ggert <eggert@cs.ucla.edu> = schrieb am Mo., 14. Aug. 2017 um 01:49=C2=A0Uhr:
Getting back to Philipp's original bug report, Apple docu= mentation says macOS
has a facility like the Linux renameat2 system call (i.e., it's like &#= 39;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-insensitivit= y
test would no longer need to be done in macOS. If there's some way to i= mplement
renameat_noreplace on MS-Windows we could get rid of the case-insensitivity= test
there too.

I don't have easy access to macOS so I have not installed this patch. I= t'd be
nice, Philipp, if you could try it out.


Thanks, the patch fixes the problem. H= owever, it's still not 100% correct: now casing changes such as from &q= uot;A" to "a" where macOS treats the file names as equivalen= t trigger the "file already exists" signal as well. I don't t= hink that can be fixed, though; there's no way to special-case casing c= hanges while keeping atomicity intact. So I'd rather have Emacs react c= onservatively and skip the casing check entirely.
Note that the m= anpage says:

RENAME_EXCL =C2=A0 On file systems= that support it (see getattrlist(2) VOL_CAP_INT_RENAME_EXCL), it will caus= e EEXIST to be=C2= =A0returned if the destination already exists.=C2=A0

I interpret this such that if the filesystem doesn't su= pport RENAME_EXCL the rename will succeed even if the destination exists.

Since we probably won't be able to solve = all issues across operating systems and filesystems, probably we should hav= e at least a warning in the documentation that rename-file attempts to be r= ace-free and atomic, but only on a best-effort basis.

--001a1143b6f2ac424f0556b97618--