From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation Date: Mon, 14 Aug 2017 16:03:13 -0700 Organization: UCLA Computer Science Department Message-ID: <0a79089f-36ed-8183-a3bf-6cfa32cb9028@cs.ucla.edu> 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/mixed; boundary="------------71DD1EB27FBD50BE6ED2022A" X-Trace: blaine.gmane.org 1502751864 1877 195.159.176.226 (14 Aug 2017 23:04:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 14 Aug 2017 23:04:24 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 Cc: 27986@debbugs.gnu.org To: Philipp Stephani Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Aug 15 01:04:17 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 1dhOP2-0007z7-6I for geb-bug-gnu-emacs@m.gmane.org; Tue, 15 Aug 2017 01:04:08 +0200 Original-Received: from localhost ([::1]:35994 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dhOP6-0005TU-KJ for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Aug 2017 19:04:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55762) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dhOOz-0005S6-7a for bug-gnu-emacs@gnu.org; Mon, 14 Aug 2017 19:04:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dhOOw-0002DV-3Y for bug-gnu-emacs@gnu.org; Mon, 14 Aug 2017 19:04:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57034) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dhOOv-0002DL-Vy for bug-gnu-emacs@gnu.org; Mon, 14 Aug 2017 19:04:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dhOOv-0001Zt-Mi for bug-gnu-emacs@gnu.org; Mon, 14 Aug 2017 19:04:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Aug 2017 23:04:01 +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.15027518066051 (code B ref 27986); Mon, 14 Aug 2017 23:04:01 +0000 Original-Received: (at 27986) by debbugs.gnu.org; 14 Aug 2017 23:03:26 +0000 Original-Received: from localhost ([127.0.0.1]:37482 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhOOM-0001ZX-6P for submit@debbugs.gnu.org; Mon, 14 Aug 2017 19:03:26 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:55902) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhOOK-0001ZR-9c for 27986@debbugs.gnu.org; Mon, 14 Aug 2017 19:03:24 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 651F81600B5; Mon, 14 Aug 2017 16:03:18 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id EUIhniDVERsK; Mon, 14 Aug 2017 16:03:17 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8028516083A; Mon, 14 Aug 2017 16:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id P8fJKZ3Q5RKz; Mon, 14 Aug 2017 16:03:17 -0700 (PDT) Original-Received: from [192.168.1.9] (unknown [47.153.184.153]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 571A3160804; Mon, 14 Aug 2017 16:03:17 -0700 (PDT) In-Reply-To: Content-Language: en-US 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:135759 Archived-At: This is a multi-part message in MIME format. --------------71DD1EB27FBD50BE6ED2022A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Philipp Stephani wrote: > 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. Yes, that makes sense, at least for macOS. > Note that the manpage says: >=20 > 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. >=20 > I interpret this such that if the filesystem doesn't support RENAME_EXC= L > the rename will succeed even if the destination exists. I interpret it to mean that if the filesystem doesn't support RENAME_EXCL= , the=20 rename will fail with errno =3D=3D EINVAL or ENOSYS. At least, that's ho= w it works=20 under GNU/Linux. If it behaved the way you suggest, there'd be no good wa= y to=20 emulate RENAME_EXCL on filesystems lacking it, which would surely not be = Apple's=20 intent. Please check this, though. I installed the patch on 'master' to help you = do that. Now that renameat_noreplace works on DOS_NT, would it make sense to apply= the=20 attached further patch as well? If we can get renameat_noreplace to work = on=20 Cygwin the we could simplify the fileio.c code even further. > 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. True. I'd like to get the directory issue fixed before worrying about thi= s,=20 though. (That way I don't have to document the security holes in the curr= ent=20 implementation. :-) I'll follow up separately about that. --------------71DD1EB27FBD50BE6ED2022A Content-Type: text/x-patch; name="0001-Improve-rename-file-behavior-on-DOS_NT.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0001-Improve-rename-file-behavior-on-DOS_NT.patch" =46rom c929fb0ed882f15e492caff9f6610c87a57bca9a Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 14 Aug 2017 15:59:37 -0700 Subject: [PATCH] Improve rename-file behavior on DOS_NT See Bug#27986. * src/fileio.c (Frename_file): Do not worry about file name case sensitivity if DOS_NT, since renameat_noreplace should work in that case. --- src/fileio.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/src/fileio.c b/src/fileio.c index 9f6de5b6ca..f5000352ab 100644 --- a/src/fileio.c +++ b/src/fileio.c @@ -2254,12 +2254,13 @@ This is what happens in interactive use with M-x.= */) =20 file =3D Fexpand_file_name (file, Qnil); =20 - /* If the filesystem is case-insensitive and the file names are - identical but for case, treat it as a change-case request, and do - not worry whether NEWNAME exists or whether it is a directory, as - it is already another name for FILE. */ + /* If renameat_noreplace does not work and the filesystem is + case-insensitive and the file names are identical but for case, + treat it as a change-case request, and do not worry whether + NEWNAME exists or whether it is a directory, as it is already + another name for FILE. */ bool case_only_rename =3D false; -#if defined CYGWIN || defined DOS_NT +#ifdef CYGWIN if (!NILP (Ffile_name_case_insensitive_p (file))) { newname =3D Fexpand_file_name (newname, Qnil); --=20 2.13.5 --------------71DD1EB27FBD50BE6ED2022A--