GNU bug report logs - #46397
27.1; Cannot delete buffer pointing to a file in a path that includes a file

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: "Peter" <craven@HIDDEN>; dated Tue, 9 Feb 2021 09:48:01 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 24 Feb 2021 18:51:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 24 13:51:17 2021
Received: from localhost ([127.0.0.1]:35941 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lEzFk-0001qx-Qi
	for submit <at> debbugs.gnu.org; Wed, 24 Feb 2021 13:51:17 -0500
Received: from eggs.gnu.org ([209.51.188.92]:54398)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lEzFj-0001ql-P8
 for 46397 <at> debbugs.gnu.org; Wed, 24 Feb 2021 13:51:16 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:39670)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lEzFd-000894-3E; Wed, 24 Feb 2021 13:51:09 -0500
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3799
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1lEzFc-0003Gd-8V; Wed, 24 Feb 2021 13:51:08 -0500
Date: Wed, 24 Feb 2021 20:50:50 +0200
Message-Id: <835z2hti45.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Matt Armstrong <matt@HIDDEN>
In-Reply-To: <m2lfbdwemq.fsf@HIDDEN> (message from Matt Armstrong
 on Wed, 24 Feb 2021 09:37:49 -0800)
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
References: <m25z2nyitm.fsf@HIDDEN> <83sg5r276b.fsf@HIDDEN>
 <m2wnv3wx1o.fsf@HIDDEN> <838s7j14xc.fsf@HIDDEN>
 <m2im6mw93c.fsf@HIDDEN> <m2lfbdwemq.fsf@HIDDEN>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 46397
Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> From: Matt Armstrong <matt@HIDDEN>
> Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
> Date: Wed, 24 Feb 2021 09:37:49 -0800
> 
> Eli, no rush but I wanted to be clear that I have paused work on this
> bug until I get more feedback from you.

Yes, I understood that.  I need to find enough time to carefully read
and review what you posted.  Sorry for being slow, but I didn't forget
nor have I dropped the ball om this.  Stay tuned.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 24 Feb 2021 17:38:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 24 12:38:03 2021
Received: from localhost ([127.0.0.1]:35842 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lEy6s-000066-Mv
	for submit <at> debbugs.gnu.org; Wed, 24 Feb 2021 12:38:02 -0500
Received: from relay11.mail.gandi.net ([217.70.178.231]:48233)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <matt@HIDDEN>) id 1lEy6q-00005b-R0
 for 46397 <at> debbugs.gnu.org; Wed, 24 Feb 2021 12:38:01 -0500
Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com
 [24.113.169.116]) (Authenticated sender: matt@HIDDEN)
 by relay11.mail.gandi.net (Postfix) with ESMTPSA id DAACB100008;
 Wed, 24 Feb 2021 17:37:52 +0000 (UTC)
From: Matt Armstrong <matt@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
In-Reply-To: <m2im6mw93c.fsf@HIDDEN>
References: <m25z2nyitm.fsf@HIDDEN> <83sg5r276b.fsf@HIDDEN>
 <m2wnv3wx1o.fsf@HIDDEN> <838s7j14xc.fsf@HIDDEN>
 <m2im6mw93c.fsf@HIDDEN>
Date: Wed, 24 Feb 2021 09:37:49 -0800
Message-ID: <m2lfbdwemq.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 46397
Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Matt Armstrong <matt@HIDDEN> writes:

> Eli Zaretskii <eliz@HIDDEN> writes:

[...]

>> I think we should audit all the callers of unlock_buffer and
>> unlock_file, and see if signaling an error there is really the best
>> alternative.

[...]

Eli, no rush but I wanted to be clear that I have paused work on this
bug until I get more feedback from you.  At this point I don't have any
more avenues that I feel I can explore, and I am unsure what more you'd
like to see before we move forward with a decision here.

I'm willing to work toward any of the options I outline below, or
something new that I have not considered.

I still like my original idea of calling display-warning for all unlock
errors, essentially turning "unlock" into a best effort function at the
API level.  I think display-warning is intrusive enough that users are
unlikely to simply not notice the problem, and there are worse things
than leaving lock files around.

I could see prompting for all errors from unlock-buffer itself, but I
have concerns about it.  As my analysis showed, the unlock operation
happens in potentially thousands of call sites in Emacs core alone.
This not counting third party elisp code.  It escallates an error to a
user interaction, which defeats mechanisms like with-demoted-errors and
other uses of condition-case.

Short of my display-warning idea, I think a reasonable option is to
handle unlock errors in targeted places.  This isn't a particularly
radical idea, I think.  The only two we know to be very problematic for
users is kill-buffer and kill-emacs.

That is my summary of where the discussion is at.  Let me know how you'd
like to proceed.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 22 Feb 2021 19:25:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 22 14:25:12 2021
Received: from localhost ([127.0.0.1]:57577 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lEGpT-0006EB-VF
	for submit <at> debbugs.gnu.org; Mon, 22 Feb 2021 14:25:12 -0500
Received: from relay10.mail.gandi.net ([217.70.178.230]:44607)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gmatta@HIDDEN>) id 1lEGpR-0006Du-Io
 for 46397 <at> debbugs.gnu.org; Mon, 22 Feb 2021 14:25:10 -0500
Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com
 [24.113.169.116]) (Authenticated sender: matt@HIDDEN)
 by relay10.mail.gandi.net (Postfix) with ESMTPSA id 91F18240005;
 Mon, 22 Feb 2021 19:25:00 +0000 (UTC)
From: Matt Armstrong <gmatta@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: [PATCH] Re: bug#46397: 27.1; Cannot delete buffer pointing to a
 file in a path that includes a file
In-Reply-To: <m2ft1w25xa.fsf@HIDDEN>
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
 <m2blcskbyq.fsf@HIDDEN> <83a6scj745.fsf@HIDDEN>
 <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN>
 <m2blcqckv7.fsf@HIDDEN>
 <f7079852-58f6-1eb4-9d68-35251c1938ff@HIDDEN>
 <83tuqhg3j9.fsf@HIDDEN> <m2wnvcahtt.fsf@HIDDEN>
 <83czx4e5h5.fsf@HIDDEN> <m2v9av8od4.fsf@HIDDEN>
 <83zh06a1yv.fsf@HIDDEN> <m24kie8fdf.fsf@HIDDEN>
 <83wnv99xkz.fsf@HIDDEN> <m2ft1w25xa.fsf@HIDDEN>
Date: Mon, 22 Feb 2021 11:24:56 -0800
Message-ID: <m2o8gb7vnb.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: Tags: patch Attached is a rev of my prior patch to add some
 test coverage for src/filelock.c. P.S. my FSF copyright papers are done. 
 Content analysis details:   (1.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
 [217.70.178.230 listed in wl.mailspike.net]
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [217.70.178.230 listed in list.dnswl.org]
 1.0 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (gmatta[at]gmail.com)
 1.0 FORGED_GMAIL_RCVD      'From' gmail.com does not match 'Received'
 headers
X-Debbugs-Envelope-To: 46397
Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

--=-=-=
Content-Type: text/plain

Tags: patch

Attached is a rev of my prior patch to add some test coverage for
src/filelock.c.

P.S. my FSF copyright papers are done.


--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
 filename=0001-Add-some-test-coverage-for-src-filelock.c-Bug-46397.patch

From 18529d097624e0d4647cf04118d4ce98adc474ba Mon Sep 17 00:00:00 2001
From: Matt Armstrong <matt@HIDDEN>
Date: Mon, 15 Feb 2021 12:59:08 -0800
Subject: [PATCH] Add some test coverage for src/filelock.c (Bug#46397).

* test/src/filelock-tests.el: New file.
---
 test/src/filelock-tests.el | 148 +++++++++++++++++++++++++++++++++++++
 1 file changed, 148 insertions(+)
 create mode 100644 test/src/filelock-tests.el

diff --git a/test/src/filelock-tests.el b/test/src/filelock-tests.el
new file mode 100644
index 0000000000..d9534e2d16
--- /dev/null
+++ b/test/src/filelock-tests.el
@@ -0,0 +1,148 @@
+;;; filelock-tests.el --- test file locking -*- lexical-binding: t; -*-
+
+;; Copyright (C) 2021  Free Software Foundation, Inc.
+
+;; This file is part of GNU Emacs.
+
+;; GNU Emacs is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+
+;; This file tests code in src/filelock.c and related buffer and file
+;; I/O code.
+
+;;; Code:
+
+(require 'ert)
+
+(defun filelock-tests--supported-p ()
+  "Return t if the current system implements file locking."
+  (not (memq system-type '(ms-dos))))
+
+(defun filelock-tests--call-with-fixture (body)
+  "Call BODY under a standard test fixture.
+See `filelock-tests--with-fixture'."
+  (let* ((test-dir (make-temp-file "filelock-tests-" t))
+         (test-dir-modes (file-modes test-dir)))
+    (unwind-protect
+        (let ((file-name (file-truename
+                          (concat (file-name-as-directory test-dir)
+                                  "file"))))
+          (with-temp-buffer
+            (let ((temp-buffer (current-buffer)))
+              ;; Setting both file names is sufficient to enable file
+              ;; locks.
+              (setq buffer-file-name file-name
+                    buffer-file-truename file-name)
+              (unwind-protect
+                  (let ((create-lockfiles t))
+                    (funcall body))
+                (set-file-modes test-dir test-dir-modes)
+                (when (buffer-live-p temp-buffer)
+                  (with-current-buffer temp-buffer
+                    (set-buffer-modified-p nil)))))))
+      (delete-directory test-dir t nil))))
+
+(defmacro filelock-tests--with-fixture (&rest body)
+  "Create a test fixture evaluate BODY there like `progn'.
+Create a temporary directory, then create a temporary buffer and
+set it the variable `buffer-file-name' and `buffer-file-truename'
+to it, let bind `create-lockfiles' to 't' and evaluate BODY.
+Finally, delete the temporary directory."
+  (declare (indent 0))
+  `(filelock-tests--call-with-fixture
+    (lambda () ,@body)))
+
+(ert-deftest filelock-tests-when-create-lockfiles-nil ()
+  (filelock-tests--with-fixture
+   (let ((create-lockfiles nil))
+     (should (not (file-locked-p buffer-file-truename)))
+     (insert "some text")
+     (lock-buffer)
+     (should (not (file-locked-p buffer-file-truename))))))
+
+(ert-deftest filelock-tests-when-create-lockfiles-t ()
+  (filelock-tests--with-fixture
+    (should (equal t create-lockfiles))
+    (insert "some text")
+    (lock-buffer)
+    ;; Verify 't' explicitly and not any true value; 't' alone means
+    ;; the current process owns the lock.
+    (let ((expected (if (filelock-tests--supported-p)
+                        t
+                      nil)))
+      (should (equal expected (file-locked-p buffer-file-truename)))
+      (unlock-buffer)
+      (should (equal nil (file-locked-p buffer-file-truename))))))
+
+(ert-deftest filelock-tests-file-locked-p-inaccessible-dir ()
+  (skip-unless (filelock-tests--supported-p))
+  (filelock-tests--with-fixture
+    (set-file-modes (file-name-directory (buffer-file-name))
+                    (file-modes-symbolic-to-number "ugo="))
+    (set-buffer-modified-p t)
+    (let ((full-error (should-error (file-locked-p (buffer-file-name))
+                                    :type 'file-error)))
+      (should (equal "Testing file lock" (nth 1 full-error))))))
+
+(ert-deftest filelock-tests-lock-buffer-inaccessible-dir ()
+  (skip-unless (filelock-tests--supported-p))
+  (filelock-tests--with-fixture
+    (let* ((test-dir (file-name-directory (buffer-file-name)))
+           (original-modes (file-modes test-dir)))
+      (set-file-modes test-dir (file-modes-symbolic-to-number "ugo="))
+      (insert "some text")
+      ;; FIXME: (lock-buffer) should signal an error here.
+      (lock-buffer)
+      (set-file-modes test-dir original-modes)
+      (should (equal nil (file-locked-p (buffer-file-name)))))))
+
+(ert-deftest filelock-tests-lock-buffer-dir-not-writeable ()
+  (skip-unless (filelock-tests--supported-p))
+  (filelock-tests--with-fixture
+    (set-file-modes (file-name-directory (buffer-file-name))
+                    (file-modes-symbolic-to-number "u=rx"))
+    (insert "some text")
+    ;; FIXME: (lock-buffer) should signal here, but lock_file() in
+    ;; filelock.c ignores some file system errors; see the related
+    ;; FIXME there.
+    (lock-buffer)
+    (should (equal nil (file-locked-p (buffer-file-name))))))
+
+(ert-deftest filelock-tests-unlock-buffer-inaccessible-dir ()
+  (skip-unless (filelock-tests--supported-p))
+  (filelock-tests--with-fixture
+    (insert "some text")
+    (lock-buffer)
+    (should (file-locked-p (buffer-file-name)))
+    (set-file-modes (file-name-directory (buffer-file-name))
+                    (file-modes-symbolic-to-number "ugo="))
+    (let ((full-error (should-error (unlock-buffer)
+                                    :type 'file-error)))
+      (should (equal "Unlocking file" (nth 1 full-error))))))
+
+(ert-deftest filelock-tests-unlock-buffer-dir-not-writeable ()
+  (skip-unless (filelock-tests--supported-p))
+  (filelock-tests--with-fixture
+    (insert "some text")
+    (should (file-locked-p (buffer-file-name)))
+    (set-file-modes (file-name-directory (buffer-file-name))
+                    (file-modes-symbolic-to-number "u=rx"))
+    (let ((full-error (should-error (unlock-buffer)
+                                    :type 'file-error)))
+      (should (equal "Unlocking file" (nth 1 full-error))))))
+
+(provide 'filelock-tests)
+
+;;; filelock-tests.el ends here
-- 
2.30.0


--=-=-=--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 22 Feb 2021 01:42:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 21 20:42:56 2021
Received: from localhost ([127.0.0.1]:55307 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lE0FU-0000XR-0O
	for submit <at> debbugs.gnu.org; Sun, 21 Feb 2021 20:42:56 -0500
Received: from relay11.mail.gandi.net ([217.70.178.231]:60445)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <matt@HIDDEN>) id 1lE0FQ-0000XB-MU
 for 46397 <at> debbugs.gnu.org; Sun, 21 Feb 2021 20:42:55 -0500
Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com
 [24.113.169.116]) (Authenticated sender: matt@HIDDEN)
 by relay11.mail.gandi.net (Postfix) with ESMTPSA id 49F5E100002;
 Mon, 22 Feb 2021 01:42:41 +0000 (UTC)
From: Matt Armstrong <matt@HIDDEN>
To: Mike Kupfer <mkupfer@HIDDEN>
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
In-Reply-To: <16051.1613951017@alto>
References: <16051.1613951017@alto>
Date: Sun, 21 Feb 2021 17:42:38 -0800
Message-ID: <m21rd8zxm9.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 46397
Cc: Eli Zaretskii <eliz@HIDDEN>, eggert@HIDDEN, 46397 <at> debbugs.gnu.org,
 craven@HIDDEN, wohler@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Mike Kupfer <mkupfer@HIDDEN> writes:

> (Adding Bill Wohler, who has a better grasp than I about why MH-E does
> some things.)
>
> Matt Armstrong wrote:
>
>> Eli Zaretskii <eliz@HIDDEN> writes:
>> 
>> > I think we should audit all the callers of unlock_buffer and
>> > unlock_file, and see if signaling an error there is really the best
>> > alternative.
> [...]
>> 	* lisp/mh-e/mh-show.el (mh-clean-msg-header, mh-unvisit-file):
>>     	  hard to say, very old code...
>> 	* lisp/mh-e/mh-comp.el (mh-read-draft): ditto.
>
> I'm not sure I completely understanding the logic behind those calls to
> unlock-buffer, but I'll take a stab at it.

[...]

Thanks for those analysis Mike.  They make sense to me.


> But to Eli's question, I think a signal is fine for MH-E if the
> lockfile can't be removed for some reason.  An uncaught signal could
> leave the current buffer in an odd state, but the user can simply kill
> the buffer and retry whatever operation she had attempted.

Yes, and this bug is at least in part about the behavior of
`kill-buffer' when faced with the same issue.  That and `kill-emacs'.


> Or if the buffer has something that is worth saving, the user can
> attempt to save the buffer somewhere, perhaps a different filesystem
> (e.g., if the original filesystem went read-only due to the OS
> detecting a problem).

I think the "buffer has something worth saving" case is not a concern.

The calls to `unlock-buffer' all occur after the buffer contents have
been saved, or otherwise marked as unmodified, or, in the case of
`kill-buffer', after the user has chosen to not save a modified buffer.


> I don't understand the proposal for unlock-buffer (or something under
> it) to prompt the user.  IIUC, the proposal is for a prompt like
>
>> /tmp/x/y lock is invalid; assume unlocked? (yes or no)
>
> I assume that if the user responds with "yes", unlock-buffer returns
> and the caller is none the wiser.  If the user responds with "no",
> what happens?
>
> mike

I think under the current idea, in the case of `kill-buffer', answering
"no" from the prompt the buffer un-killed.  I think the technical
mechanism would be to either re-signal the underlying 'file-error or
signal a new 'unlock-error that contains similar information.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 21 Feb 2021 23:43:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 21 18:43:56 2021
Received: from localhost ([127.0.0.1]:55262 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lDyOK-0006EC-4I
	for submit <at> debbugs.gnu.org; Sun, 21 Feb 2021 18:43:56 -0500
Received: from shell1.rawbw.com ([198.144.192.42]:15322 ident=root)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mkupfer@HIDDEN>) id 1lDyOF-0006E0-KJ
 for 46397 <at> debbugs.gnu.org; Sun, 21 Feb 2021 18:43:54 -0500
Received: from alto (96-95-200-133-static.hfc.comcastbusiness.net
 [96.95.200.133]) (authenticated bits=0)
 by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id 11LNhbXc020081
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Sun, 21 Feb 2021 15:43:43 -0800 (PST)
 (envelope-from mkupfer@HIDDEN)
X-Authentication-Warning: shell1.rawbw.com: Host
 96-95-200-133-static.hfc.comcastbusiness.net [96.95.200.133] claimed to be
 alto
From: Mike Kupfer <mkupfer@HIDDEN>
To: Matt Armstrong <matt@HIDDEN>
Subject: Re: bug#46397: 27.1;
 Cannot delete buffer pointing to a file in a path that includes a file
In-Reply-To: Your message of "Sat, 20 Feb 2021 16:36:07 -0800."
 <m2im6mw93c.fsf@HIDDEN>
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 27.1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <16050.1613951017.1@alto>
Date: Sun, 21 Feb 2021 15:43:37 -0800
Message-ID: <16051.1613951017@alto>
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 46397
Cc: Eli Zaretskii <eliz@HIDDEN>, eggert@HIDDEN, 46397 <at> debbugs.gnu.org,
 craven@HIDDEN, wohler@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

(Adding Bill Wohler, who has a better grasp than I about why MH-E does
some things.)

Matt Armstrong wrote:

> Eli Zaretskii <eliz@HIDDEN> writes:
> 
> > I think we should audit all the callers of unlock_buffer and
> > unlock_file, and see if signaling an error there is really the best
> > alternative.
[...]
> 	* lisp/mh-e/mh-show.el (mh-clean-msg-header, mh-unvisit-file):
>     	  hard to say, very old code...
> 	* lisp/mh-e/mh-comp.el (mh-read-draft): ditto.

I'm not sure I completely understanding the logic behind those calls to
unlock-buffer, but I'll take a stab at it.

mh-unvisit-file: this function's purpose in life is to disassociate the
current buffer from the underlying file.  (MH-E reuses a per-folder
buffer when displaying a message.)

mh-read-draft: this case is similar to mh-unvisit-file.  In the relevant
code path, the user's configuration allows for only a single "draft"
buffer, and MH-E is cleaning up a potentially old draft buffer for
reuse.

mh-clean-msg-header: this one confuses me.  mh-clean-msg-header edits
the current buffer to reflect the user's preferences for which mail
headers to display.  But there are several places where
mh-clean-msg-header is used, and I haven't figured out if the buffer
ever has an associated file when mh-clean-msg-header is called.  So I'm
not even sure the call to unlock-buffer actually has any value here.

But to Eli's question, I think a signal is fine for MH-E if the lockfile
can't be removed for some reason.  An uncaught signal could leave the
current buffer in an odd state, but the user can simply kill the buffer
and retry whatever operation she had attempted.  Or if the buffer has
something that is worth saving, the user can attempt to save the buffer
somewhere, perhaps a different filesystem (e.g., if the original
filesystem went read-only due to the OS detecting a problem).

I don't understand the proposal for unlock-buffer (or something under
it) to prompt the user.  IIUC, the proposal is for a prompt like

> /tmp/x/y lock is invalid; assume unlocked? (yes or no)

I assume that if the user responds with "yes", unlock-buffer returns and
the caller is none the wiser.  If the user responds with "no", what
happens?

mike




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 21 Feb 2021 00:36:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 20 19:36:23 2021
Received: from localhost ([127.0.0.1]:53218 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lDcjW-0002s7-SM
	for submit <at> debbugs.gnu.org; Sat, 20 Feb 2021 19:36:23 -0500
Received: from relay8-d.mail.gandi.net ([217.70.183.201]:59459)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <matt@HIDDEN>) id 1lDcjU-0002rq-PH
 for 46397 <at> debbugs.gnu.org; Sat, 20 Feb 2021 19:36:21 -0500
X-Originating-IP: 24.113.169.116
Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com
 [24.113.169.116]) (Authenticated sender: matt@HIDDEN)
 by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 4E9491BF204;
 Sun, 21 Feb 2021 00:36:10 +0000 (UTC)
From: Matt Armstrong <matt@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
In-Reply-To: <838s7j14xc.fsf@HIDDEN>
References: <m25z2nyitm.fsf@HIDDEN> <83sg5r276b.fsf@HIDDEN>
 <m2wnv3wx1o.fsf@HIDDEN> <838s7j14xc.fsf@HIDDEN>
Date: Sat, 20 Feb 2021 16:36:07 -0800
Message-ID: <m2im6mw93c.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 46397
Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: Matt Armstrong <matt@HIDDEN>
>> Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
>> Date: Fri, 19 Feb 2021 13:46:27 -0800
>> 
>> >> I'm coming to the opinion that issuing a prompt from `unlock-buffer'
>> >> itself is a bad idea, but I think prompting from `kill-buffer' is
>> >> okay.
>> >
>> > What do you propose to do for all the other users of unlock-buffer?
>> 
>> They continue to signal errors.
>> 
>> I would be happy to send a list of reasons why I think this is a safer
>> thing to do than prompting.  (reasons that I admit I could be misguided)
>
> I think we should audit all the callers of unlock_buffer and
> unlock_file, and see if signaling an error there is really the best
> alternative.

I had already started something like this so I finished it off.  See the
end of this email.  It is long.


> I still think that prompting the user for what to do, with one of the
> possible responses being "ignore", could be a better solution, at
> least in some of these cases, because signaling an error means the
> results of some operation are lost.

I share the concern about losing work due to unlock errors.  I become
annoyed any time a program fails or asks me questions for unecessary
reasons.


> For example, consider replace-buffer-contents, which is a command --
> we could signal the error there after everything, all the heavy
> processing, has been done already.  Is that reasonable?

I think I can agree that this kind of detail oriented approach can
definitely make individual functions better at leaving the data
structures they modify in well defined states, even in the face of
error.

I am not sure how to apply this idea to this discussion, however.  It
seems like a more general observation about writing "exception safe"
code.

Or perhaps I am missing what you are saying?


> Or are you relying on the ability of unlock_file to silently ignore
> the errors where the user should choose "ignore"?  Because I'd like to
> explicitly NOT rely on that.

My current idea is to keep unlock file exactly the same, in that it
signals errors the way it does today.  Then, surgically improve the only
two places in Emacs where we know this is a serious problem.

My other idea was to change the unlock functions to never signal an
errors, but instead report them through `display-warning', perhaps with
warning level :error.  This is still my personally preferred option, but
I know that you don't like it.

Still another idea is to modify `unlock_file' itself to issue a user
prompt.  This is by far my least favorite approach because the
implications of such a large change for such a comparatively minor issue
terrify me.

I should say, in case I haven't before, that I am quite willing to put
my preferences aside here.  I have no experience maintaining Emacs.

I do have a great deal of experience maintaining large, very complex but
also robust server based systems.  There, being very "loud and obvious"
for every anomolous condition that could possibly be a problem just
doesn't work -- it is just too much information.  In systems large
enough the "rare" things are basically always happening!  With that kind
of software it tends to be most important to limit reported errors to
truly important issues that indicate a failure to satisfy requests
within well defined criteria.  The "softer" anomolous conditions are
demoted to warnings that are available for diagnostic analysis if
needed.  The approach, done right, provides the correct level of detail
to diagnose problems when the need arises.

I will say that this design conversation has been quite a surprise.  In
my former "server based" world I would have sent a code review to demote
unlock errors to `display-error' and it would have been approved with
little discussion!  We did that kind of thing all the time, and it was
just "undersood" best practice.  :-)


> So yes, a list of callers and the reasons not to prompt the user there
> would be a good starting point, TIA.

Could prompting from essentially arbitrary places in Emacs be made safer
with a modal `reach-char' based approach?  This is what userlock.el does
in `ask-user-about-lock'.  It avoids the "anything can happen here"
issue that non-modal prompts have, so it feels like a safer thing to do
if it ends up that we decide to make "unlock buffer" and "unlock file"
prompt the user.

Prompts, whether model or not, are difficult for me to assess in terms
of risks.  At this point I definitely value the intuition of long time
Emacs hackers over my own ability to read and reason about Emacs code.

A second issue is what to ask the user.  Prompting the user to either
ignore or signal an error feels quite low level.  Paul suggested:

     /tmp/x/y lock is invalid; assume unlocked? (yes or no)

But I would argue that the consequences of answering "yes" or "no" to
that kind of question are not clear.

Not to beat a dead horse, but a *Warning* buffer based approach from
`display-error' would be clearer.  Something like:

  Warning (unlock-file): Could not unlock buffer <myfile>,
  Permission Denied, /blah/blah/.#myfile

For one, the command the user issued would succeed, with no extra
interaction required from them, so they'd immediately know that things
worked, but for this one strange issue.  This is similar to auto-save in
intent.  Both auto save and lock file management happen "in the
background" -- out of sight, and out of mind until they are needed.
They aren't things the user manages, or should be asked to manage errors
from, IMO.


>> >>  (a) Modify `kill-buffer' to call `unlock-buffer' sooner, closer to the
>> >>      point where it is already running hooks prompting the user.
>> >
>> > Why do we need to move the call?  Can we leave it in its current
>> > place, and thus minimize potential unintended problems this could
>> > cause?
>> 
>> In part because `kill-buffer' currently calls `unlock-buffer' after this
>> comment:
>> 
>>   /* We have no more questions to ask.  Verify that it is valid
>>      to kill the buffer.  This must be done after the questions
>>      since anything can happen within do_yes_or_no_p.  */
>
> OK, but then the call to unlock_buffer should have all the conditions
> tested later, under which we will NOT kill the buffer.  Because
> otherwise we could pop the question for a buffer that we are not going
> to kill.
>
>> (This class of problem is also one of the reasons for my answer above.)
>
> When the alternative is worse than what could possibly happen inside
> do_yes_or_no_p, we may decide to ask the question anyway.

Yes, we're often forced to choose the "least worse" option.


Returning to the code audit:

> I think we should audit all the callers of unlock_buffer and
> unlock_file, and see if signaling an error there is really the best
> alternative.

This is a difficult analysis due to the number call sites.  In emacs.git
there are 1600 call sites to lisp level functions that might call
`unlock-file'.

I'll use `func' for Lisp functions and func() for C functions.  The call
counts I cite below are limited to callers in emacs.git.

I looked at call sites of only the core level commands.  There are too
many indirect callers to do more than that.  In each call site, I
thought about whether the code looked like it had obvious problems if
errors were signaled from calls that unlocked, and also whether the code
might have especially delicate invariants that might break if code
entered the kind of quasi "recursive edit" operation that a non-modal
prompts imply.

unlock_file() is an implementation detail at the C level, which has a
few major callers:

`write-region' can open/close the destination file, locking/unlocking it
as well.  This function also provides LOCKNAME, an Emacs Lisp level
override for the lock file name.  It is has ~500 call sites.

`insert-file-contents' usually takes a file from unlocked->locked and
leaves it locked, but it will unlock if it turns out the buffer contents
did not change.  It also calls unlock_file() in certain cases when
`find-file-name-handler' returns nil (why I don't quite understand).  It
has ~750 call sites.

`replace-buffer-contents' is similar: it locks but will then unlock if
the buffer contents do not change.  It has 16 call sites.

`restore-buffer-modified-p' will unlock the file if the buffer becomes
unmodified.  It has ~51 call sites.

`set-buffer-modified-p` will unlock if passed 'nil'.  There are ~400
call sites with ~290 of them matching the literal expression
(set-buffer-modified-p nil).

`unlock-buffer' does the obvious, with few direct call sites, so I
looked at them all.  Some were redundant -- occuring just before or
after (set-buffer-modified nil).  The rest:

	* lisp/jka-compr.el (jka-compr-insert-file-contents): No obvious
          (to me) problem if `unlock-file' signals an error.

	* lisp/simple.el (primitive-undo): resuming after arbitrary
          interactions (i.e. a non-modal prompt) might screw up the undo
          invariants?

	* lisp/mh-e/mh-show.el (mh-clean-msg-header, mh-unvisit-file):
    	  hard to say, very old code...
	* lisp/mh-e/mh-comp.el (mh-read-draft): ditto.

	* lisp/files.el (find-alternate-file): Signaled errors from
	(unlock-file) look okay.  It occurs under an (unwind-protect...)
	which has UNWINDFORMS that look good to me.
	(set-visited-file-name): No obvious problem.
	(revert-buffer-insert-file-contents--default-function): No obvious
	problems.

	* lisp/simple.el (primitive-undo): Signaled unlock errors may
	case broken undo invariants?  I am not too worried, since undo
	can also lock the file.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 20 Feb 2021 09:10:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 20 04:10:02 2021
Received: from localhost ([127.0.0.1]:51000 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lDOH3-0006uN-JA
	for submit <at> debbugs.gnu.org; Sat, 20 Feb 2021 04:10:02 -0500
Received: from eggs.gnu.org ([209.51.188.92]:36400)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lDOH1-0006u2-Cr
 for 46397 <at> debbugs.gnu.org; Sat, 20 Feb 2021 04:09:59 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:40864)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lDOGu-0003w5-RI; Sat, 20 Feb 2021 04:09:52 -0500
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2453
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1lDOGu-0004Rn-4U; Sat, 20 Feb 2021 04:09:52 -0500
Date: Sat, 20 Feb 2021 11:09:35 +0200
Message-Id: <838s7j14xc.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Matt Armstrong <matt@HIDDEN>
In-Reply-To: <m2wnv3wx1o.fsf@HIDDEN> (message from Matt Armstrong
 on Fri, 19 Feb 2021 13:46:27 -0800)
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
References: <m25z2nyitm.fsf@HIDDEN> <83sg5r276b.fsf@HIDDEN>
 <m2wnv3wx1o.fsf@HIDDEN>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 46397
Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> From: Matt Armstrong <matt@HIDDEN>
> Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
> Date: Fri, 19 Feb 2021 13:46:27 -0800
> 
> >> I'm coming to the opinion that issuing a prompt from `unlock-buffer'
> >> itself is a bad idea, but I think prompting from `kill-buffer' is
> >> okay.
> >
> > What do you propose to do for all the other users of unlock-buffer?
> 
> They continue to signal errors.
> 
> I would be happy to send a list of reasons why I think this is a safer
> thing to do than prompting.  (reasons that I admit I could be misguided)

I think we should audit all the callers of unlock_buffer and
unlock_file, and see if signaling an error there is really the best
alternative.  I still think that prompting the user for what to do,
with one of the possible responses being "ignore", could be a better
solution, at least in some of these cases, because signaling an error
means the results of some operation are lost.  For example, consider
replace-buffer-contents, which is a command -- we could signal the
error there after everything, all the heavy processing, has been done
already.  Is that reasonable?  Or are you relying on the ability of
unlock_file to silently ignore the errors where the user should choose
"ignore"?  Because I'd like to explicitly NOT rely on that.

So yes, a list of callers and the reasons not to prompt the user there
would be a good starting point, TIA.

> >>  (a) Modify `kill-buffer' to call `unlock-buffer' sooner, closer to the
> >>      point where it is already running hooks prompting the user.
> >
> > Why do we need to move the call?  Can we leave it in its current
> > place, and thus minimize potential unintended problems this could
> > cause?
> 
> In part because `kill-buffer' currently calls `unlock-buffer' after this
> comment:
> 
>   /* We have no more questions to ask.  Verify that it is valid
>      to kill the buffer.  This must be done after the questions
>      since anything can happen within do_yes_or_no_p.  */

OK, but then the call to unlock_buffer should have all the conditions
tested later, under which we will NOT kill the buffer.  Because
otherwise we could pop the question for a buffer that we are not going
to kill.

> (This class of problem is also one of the reasons for my answer above.)

When the alternative is worse than what could possibly happen inside
do_yes_or_no_p, we may decide to ask the question anyway.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 19 Feb 2021 21:52:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 19 16:52:51 2021
Received: from localhost ([127.0.0.1]:50551 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lDDhj-0007f6-IX
	for submit <at> debbugs.gnu.org; Fri, 19 Feb 2021 16:52:51 -0500
Received: from relay3-d.mail.gandi.net ([217.70.183.195]:51727)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <matt@HIDDEN>) id 1lDDhh-0007es-CI
 for 46397 <at> debbugs.gnu.org; Fri, 19 Feb 2021 16:52:50 -0500
X-Originating-IP: 24.113.169.116
Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com
 [24.113.169.116]) (Authenticated sender: matt@HIDDEN)
 by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 04D2760003;
 Fri, 19 Feb 2021 21:52:39 +0000 (UTC)
From: Matt Armstrong <matt@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
In-Reply-To: <fd4b247f-2795-cc94-eb40-ee05fca01c1e@HIDDEN>
References: <m25z2nyitm.fsf@HIDDEN>
 <fd4b247f-2795-cc94-eb40-ee05fca01c1e@HIDDEN>
Date: Fri, 19 Feb 2021 13:52:36 -0800
Message-ID: <m2tuq7wwrf.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 46397
Cc: 46397 <at> debbugs.gnu.org, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Paul Eggert <eggert@HIDDEN> writes:

> On 2/19/21 11:10 AM, Matt Armstrong wrote:
>>   (a) Modify `kill-buffer' to call `unlock-buffer' sooner, closer to the
>>       point where it is already running hooks prompting the user.  Handle
>>       unlock errors there by prompting.
>
> How would unlock-buffer's API change, so that kill-buffer and 
> unlock-buffer's other callers can do the right thing? Would it signal an 
> error, and if so which one (or a new kind of error)?

unlock-buffer signals file errors today, and that wouldn't change under
this idea.

I suppose we could invent a new 'file-unlock-error if we think the
caller may want to discriminate, but so far my prototype in `kill-buffer
just handles any 'file-error that `unlock-buffer' happens to signal.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 19 Feb 2021 21:46:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 19 16:46:42 2021
Received: from localhost ([127.0.0.1]:50547 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lDDbl-0007WZ-PR
	for submit <at> debbugs.gnu.org; Fri, 19 Feb 2021 16:46:42 -0500
Received: from relay6-d.mail.gandi.net ([217.70.183.198]:57683)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <matt@HIDDEN>) id 1lDDbj-0007WF-4Z
 for 46397 <at> debbugs.gnu.org; Fri, 19 Feb 2021 16:46:39 -0500
X-Originating-IP: 24.113.169.116
Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com
 [24.113.169.116]) (Authenticated sender: matt@HIDDEN)
 by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 254FCC0003;
 Fri, 19 Feb 2021 21:46:30 +0000 (UTC)
From: Matt Armstrong <matt@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
In-Reply-To: <83sg5r276b.fsf@HIDDEN>
References: <m25z2nyitm.fsf@HIDDEN> <83sg5r276b.fsf@HIDDEN>
Date: Fri, 19 Feb 2021 13:46:27 -0800
Message-ID: <m2wnv3wx1o.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 46397
Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: Matt Armstrong <matt@HIDDEN>
>> Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
>> Date: Fri, 19 Feb 2021 11:10:45 -0800
>> 
>> I'm coming to the opinion that issuing a prompt from `unlock-buffer'
>> itself is a bad idea, but I think prompting from `kill-buffer' is
>> okay.
>
> What do you propose to do for all the other users of unlock-buffer?

They continue to signal errors.

I would be happy to send a list of reasons why I think this is a safer
thing to do than prompting.  (reasons that I admit I could be misguided)


>> I could write a whole essay about why, but instead I'll just
>> propose the following and ask for your thoughts:
>> 
>>  (a) Modify `kill-buffer' to call `unlock-buffer' sooner, closer to the
>>      point where it is already running hooks prompting the user.
>
> Why do we need to move the call?  Can we leave it in its current
> place, and thus minimize potential unintended problems this could
> cause?

In part because `kill-buffer' currently calls `unlock-buffer' after this
comment:

  /* We have no more questions to ask.  Verify that it is valid
     to kill the buffer.  This must be done after the questions
     since anything can happen within do_yes_or_no_p.  */

(This class of problem is also one of the reasons for my answer above.)




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 19 Feb 2021 19:45:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 19 14:45:33 2021
Received: from localhost ([127.0.0.1]:50428 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lDBiX-0004bc-5M
	for submit <at> debbugs.gnu.org; Fri, 19 Feb 2021 14:45:33 -0500
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:52756)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1lDBiU-0004bO-Vj
 for 46397 <at> debbugs.gnu.org; Fri, 19 Feb 2021 14:45:31 -0500
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5341C160017;
 Fri, 19 Feb 2021 11:45:25 -0800 (PST)
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 KsG-5BYYaOxT; Fri, 19 Feb 2021 11:45:24 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id AB5F1160120;
 Fri, 19 Feb 2021 11:45:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
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 sodJz3ESX2EM; Fri, 19 Feb 2021 11:45:24 -0800 (PST)
Received: from [192.168.0.103] (cpe-23-243-218-95.socal.res.rr.com
 [23.243.218.95])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 7AB51160017;
 Fri, 19 Feb 2021 11:45:24 -0800 (PST)
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
To: Matt Armstrong <matt@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
References: <m25z2nyitm.fsf@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Message-ID: <fd4b247f-2795-cc94-eb40-ee05fca01c1e@HIDDEN>
Date: Fri, 19 Feb 2021 11:45:24 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <m25z2nyitm.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 46397
Cc: 46397 <at> debbugs.gnu.org, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

On 2/19/21 11:10 AM, Matt Armstrong wrote:
>   (a) Modify `kill-buffer' to call `unlock-buffer' sooner, closer to the
>       point where it is already running hooks prompting the user.  Handle
>       unlock errors there by prompting.

How would unlock-buffer's API change, so that kill-buffer and 
unlock-buffer's other callers can do the right thing? Would it signal an 
error, and if so which one (or a new kind of error)?





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 19 Feb 2021 19:23:21 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 19 14:23:21 2021
Received: from localhost ([127.0.0.1]:50407 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lDBN2-000435-8q
	for submit <at> debbugs.gnu.org; Fri, 19 Feb 2021 14:23:21 -0500
Received: from eggs.gnu.org ([209.51.188.92]:52854)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lDBMz-00042q-FA
 for 46397 <at> debbugs.gnu.org; Fri, 19 Feb 2021 14:23:18 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:56342)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lDBMs-0003BM-Q7; Fri, 19 Feb 2021 14:23:10 -0500
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3500
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1lDBMr-00007T-7y; Fri, 19 Feb 2021 14:23:09 -0500
Date: Fri, 19 Feb 2021 21:23:24 +0200
Message-Id: <83sg5r276b.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Matt Armstrong <matt@HIDDEN>
In-Reply-To: <m25z2nyitm.fsf@HIDDEN> (message from Matt Armstrong
 on Fri, 19 Feb 2021 11:10:45 -0800)
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
References: <m25z2nyitm.fsf@HIDDEN>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 46397
Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> From: Matt Armstrong <matt@HIDDEN>
> Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
> Date: Fri, 19 Feb 2021 11:10:45 -0800
> 
> I'm coming to the opinion that issuing a prompt from `unlock-buffer'
> itself is a bad idea, but I think prompting from `kill-buffer' is
> okay.

What do you propose to do for all the other users of unlock-buffer?

> I could write a whole essay about why, but instead I'll just
> propose the following and ask for your thoughts:
> 
>  (a) Modify `kill-buffer' to call `unlock-buffer' sooner, closer to the
>      point where it is already running hooks prompting the user.

Why do we need to move the call?  Can we leave it in its current
place, and thus minimize potential unintended problems this could
cause?

Thanks.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 19 Feb 2021 19:11:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 19 14:11:01 2021
Received: from localhost ([127.0.0.1]:50393 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lDBB6-0003jr-P1
	for submit <at> debbugs.gnu.org; Fri, 19 Feb 2021 14:11:01 -0500
Received: from relay2-d.mail.gandi.net ([217.70.183.194]:52979)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <matt@HIDDEN>) id 1lDBB4-0003je-JK
 for 46397 <at> debbugs.gnu.org; Fri, 19 Feb 2021 14:10:59 -0500
X-Originating-IP: 24.113.169.116
Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com
 [24.113.169.116]) (Authenticated sender: matt@HIDDEN)
 by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 8DBFF40002;
 Fri, 19 Feb 2021 19:10:50 +0000 (UTC)
From: Matt Armstrong <matt@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
In-Reply-To: <83wnv99xkz.fsf@HIDDEN>
Date: Fri, 19 Feb 2021 11:10:45 -0800
Message-ID: <m25z2nyitm.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 46397
Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: Matt Armstrong <gmatta@HIDDEN>
>> Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
>> Date: Sun, 14 Feb 2021 14:16:12 -0800
>> 
>> When releasing the lock, I have a less clear opinion but I'm thinking
>> that warnings are better. A warning is still quite intrusive and
>> obvious. Maybe we don't need to decide this part now.
>
> The problem with warnings is that they can go unnoticed, unless
> followed by sit-for.

Hello again Eli, Paul,

I've got a more concrete plan and would like some feedback on it.

While waiting for my signed FSF papers to be acknowledged I have been
investigating how to achieve a prompt in some depth.  I'm coming to the
opinion that issuing a prompt from `unlock-buffer' itself is a bad idea,
but I think prompting from `kill-buffer' is okay.  I could write a whole
essay about why, but instead I'll just propose the following and ask for
your thoughts:

 (a) Modify `kill-buffer' to call `unlock-buffer' sooner, closer to the
     point where it is already running hooks prompting the user.  Handle
     unlock errors there by prompting.  This function already prompts
     the user for the "buffer modified, save anyway" case so a new
     prompt there feels fine.

 (b) Modify Emacs shutdown to handle `unlock-buffer` errors differently
     as well (with `message' or `display-warning').

 (c) Modify `unlock-buffer' to include the buffer name in the errors it
     signals.  It currently only includes the buffer's
     `buffer-true-filename'.  With this the user can more easily find
     and kill the offending buffer.

This approach solves the concrete problems we know about, but doesn't
dramatically change Emacs behavior in other ways.  In other words, Emacs
typically signals errors for file system errors and that stays the same.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 16 Feb 2021 15:06:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 16 10:06:10 2021
Received: from localhost ([127.0.0.1]:41205 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lC1vW-0007s3-2k
	for submit <at> debbugs.gnu.org; Tue, 16 Feb 2021 10:06:10 -0500
Received: from eggs.gnu.org ([209.51.188.92]:53112)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lC1vR-0007rY-Pg
 for 46397 <at> debbugs.gnu.org; Tue, 16 Feb 2021 10:06:08 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:52857)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lC1vL-0006cJ-R9; Tue, 16 Feb 2021 10:05:59 -0500
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4639
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1lC1vG-00087B-N1; Tue, 16 Feb 2021 10:05:58 -0500
Date: Tue, 16 Feb 2021 17:06:02 +0200
Message-Id: <83czx09hnp.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-Reply-To: <3f6378f1-3e93-5625-31c0-7ce1423e3960@HIDDEN> (message from
 Paul Eggert on Mon, 15 Feb 2021 17:55:00 -0800)
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
 <m2blcskbyq.fsf@HIDDEN> <83a6scj745.fsf@HIDDEN>
 <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN>
 <m2blcqckv7.fsf@HIDDEN>
 <f7079852-58f6-1eb4-9d68-35251c1938ff@HIDDEN> <83tuqhg3j9.fsf@HIDDEN>
 <m2wnvcahtt.fsf@HIDDEN> <83czx4e5h5.fsf@HIDDEN>
 <m2v9av8od4.fsf@HIDDEN> <83zh06a1yv.fsf@HIDDEN>
 <m24kie8fdf.fsf@HIDDEN> <83wnv99xkz.fsf@HIDDEN>
 <m2ft1w25xa.fsf@HIDDEN>
 <3f6378f1-3e93-5625-31c0-7ce1423e3960@HIDDEN>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 46397
Cc: gmatta@HIDDEN, 46397 <at> debbugs.gnu.org, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> Cc: 46397 <at> debbugs.gnu.org, craven@HIDDEN
> From: Paul Eggert <eggert@HIDDEN>
> Date: Mon, 15 Feb 2021 17:55:00 -0800
> 
> On 2/15/21 4:49 PM, Matt Armstrong wrote:
> > If this kind of a test is a bad idea, feel free to let me know.
> 
> It's very much a good idea, since it helps prevent similar problems from 
> recurring. Thanks.

I agree.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 16 Feb 2021 11:53:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 16 06:53:58 2021
Received: from localhost ([127.0.0.1]:39573 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lByvV-0002d4-PJ
	for submit <at> debbugs.gnu.org; Tue, 16 Feb 2021 06:53:58 -0500
Received: from quimby.gnus.org ([95.216.78.240]:51900)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1lByvU-0002cq-OL
 for 46397 <at> debbugs.gnu.org; Tue, 16 Feb 2021 06:53:57 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:
 References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=OoU3a9E9WIa+M2hHLH30S7ED3/RYTm2U3f29KFx1h9Q=; b=qH6G5kkW0XUTaUjNl4Yk1kn3lG
 5EYZX1njXafb2+qBG6A5ipyBCpN3vve37vWsSAD05QnQpCbGyp0LfsyEsXhRBktbcbw90f91YU321
 n93MhmSQQahDj41zHkCA87VT/6On3rGrBtx5CGcQsE/kif/br7Qqbg56Rpk+sknnw7LY=;
Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1lByvK-0004kV-7E; Tue, 16 Feb 2021 12:53:49 +0100
From: Lars Ingebrigtsen <larsi@HIDDEN>
To: Matt Armstrong <gmatta@HIDDEN>
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
 <m2blcskbyq.fsf@HIDDEN> <83a6scj745.fsf@HIDDEN>
 <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN>
 <m2blcqckv7.fsf@HIDDEN>
 <f7079852-58f6-1eb4-9d68-35251c1938ff@HIDDEN>
 <83tuqhg3j9.fsf@HIDDEN> <m2wnvcahtt.fsf@HIDDEN>
 <83czx4e5h5.fsf@HIDDEN> <m2v9av8od4.fsf@HIDDEN>
 <83zh06a1yv.fsf@HIDDEN> <m24kie8fdf.fsf@HIDDEN>
 <83wnv99xkz.fsf@HIDDEN> <m2ft1w25xa.fsf@HIDDEN>
X-Now-Playing: Sevdaliza's _ISON_: "Marilyn Monroe"
Date: Tue, 16 Feb 2021 12:53:44 +0100
In-Reply-To: <m2ft1w25xa.fsf@HIDDEN> (Matt Armstrong's message of
 "Mon, 15 Feb 2021 16:49:05 -0800")
Message-ID: <87blckz0s7.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview:  Matt Armstrong <gmatta@HIDDEN> writes: > My FSF papers
 are out of date. Mind sending me new ones? I am in the > United States. Here's
 the form to get started: 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 46397
Cc: Eli Zaretskii <eliz@HIDDEN>, eggert@HIDDEN, 46397 <at> debbugs.gnu.org,
 craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Matt Armstrong <gmatta@HIDDEN> writes:

> My FSF papers are out of date. Mind sending me new ones?  I am in the
> United States.

Here's the form to get started:


Please email the following information to assign@HIDDEN, and we
will send you the assignment form for your past and future changes.

Please use your full legal name (in ASCII characters) as the subject
line of the message.
----------------------------------------------------------------------
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES

[What is the name of the program or package you're contributing to?]
Emacs

[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]

[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]

[For the copyright registration, what country are you a citizen of?]

[What year were you born?]

[Please write your email address here.]

[Please write your postal address here.]

[Which files have you changed so far, and which new files have you written
so far?]





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 16 Feb 2021 01:55:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 15 20:55:13 2021
Received: from localhost ([127.0.0.1]:39038 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lBpa4-0004J2-8B
	for submit <at> debbugs.gnu.org; Mon, 15 Feb 2021 20:55:13 -0500
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:52748)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1lBpZz-0004IX-GJ
 for 46397 <at> debbugs.gnu.org; Mon, 15 Feb 2021 20:55:10 -0500
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id D2CBA16008A;
 Mon, 15 Feb 2021 17:55:01 -0800 (PST)
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 fashUSliBbod; Mon, 15 Feb 2021 17:55:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 34A8D16008D;
 Mon, 15 Feb 2021 17:55:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
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 4pI2NtA_NCcF; Mon, 15 Feb 2021 17:55:01 -0800 (PST)
Received: from [192.168.1.9] (cpe-23-243-218-95.socal.res.rr.com
 [23.243.218.95])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 0731216008A;
 Mon, 15 Feb 2021 17:55:01 -0800 (PST)
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
To: Matt Armstrong <gmatta@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
 <m2blcskbyq.fsf@HIDDEN> <83a6scj745.fsf@HIDDEN>
 <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN>
 <m2blcqckv7.fsf@HIDDEN>
 <f7079852-58f6-1eb4-9d68-35251c1938ff@HIDDEN> <83tuqhg3j9.fsf@HIDDEN>
 <m2wnvcahtt.fsf@HIDDEN> <83czx4e5h5.fsf@HIDDEN>
 <m2v9av8od4.fsf@HIDDEN> <83zh06a1yv.fsf@HIDDEN>
 <m24kie8fdf.fsf@HIDDEN> <83wnv99xkz.fsf@HIDDEN>
 <m2ft1w25xa.fsf@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Message-ID: <3f6378f1-3e93-5625-31c0-7ce1423e3960@HIDDEN>
Date: Mon, 15 Feb 2021 17:55:00 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <m2ft1w25xa.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 46397
Cc: 46397 <at> debbugs.gnu.org, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

On 2/15/21 4:49 PM, Matt Armstrong wrote:
> If this kind of a test is a bad idea, feel free to let me know.

It's very much a good idea, since it helps prevent similar problems from 
recurring. Thanks.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 16 Feb 2021 00:49:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 15 19:49:23 2021
Received: from localhost ([127.0.0.1]:38963 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lBoYN-0002in-2y
	for submit <at> debbugs.gnu.org; Mon, 15 Feb 2021 19:49:23 -0500
Received: from relay12.mail.gandi.net ([217.70.178.232]:42135)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gmatta@HIDDEN>) id 1lBoYK-0002iX-RP
 for 46397 <at> debbugs.gnu.org; Mon, 15 Feb 2021 19:49:22 -0500
Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com
 [24.113.169.116]) (Authenticated sender: matt@HIDDEN)
 by relay12.mail.gandi.net (Postfix) with ESMTPSA id 1B7D1200003;
 Tue, 16 Feb 2021 00:49:10 +0000 (UTC)
From: Matt Armstrong <gmatta@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
In-Reply-To: <83wnv99xkz.fsf@HIDDEN>
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
 <m2blcskbyq.fsf@HIDDEN> <83a6scj745.fsf@HIDDEN>
 <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN>
 <m2blcqckv7.fsf@HIDDEN>
 <f7079852-58f6-1eb4-9d68-35251c1938ff@HIDDEN>
 <83tuqhg3j9.fsf@HIDDEN> <m2wnvcahtt.fsf@HIDDEN>
 <83czx4e5h5.fsf@HIDDEN> <m2v9av8od4.fsf@HIDDEN>
 <83zh06a1yv.fsf@HIDDEN> <m24kie8fdf.fsf@HIDDEN>
 <83wnv99xkz.fsf@HIDDEN>
Date: Mon, 15 Feb 2021 16:49:05 -0800
Message-ID: <m2ft1w25xa.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 2.3 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: Eli Zaretskii writes: >> From: Matt Armstrong >> Cc:
 46397 <at> debbugs.gnu.org, 
 eggert@HIDDEN, craven@HIDDEN >> Date: Sun, 14 Feb 2021 14:16:12 -0800
 >> >> When releasing the lock, I have a less clear opinion but I'm t [...]
 Content analysis details:   (2.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [217.70.178.232 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
 [217.70.178.232 listed in wl.mailspike.net]
 1.0 FORGED_GMAIL_RCVD      'From' gmail.com does not match 'Received'
 headers
 1.0 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (gmatta[at]gmail.com)
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 1.0 FREEMAIL_REPLY         From and body contain different freemails
X-Debbugs-Envelope-To: 46397
Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

--=-=-=
Content-Type: text/plain

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: Matt Armstrong <gmatta@HIDDEN>
>> Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
>> Date: Sun, 14 Feb 2021 14:16:12 -0800
>> 
>> When releasing the lock, I have a less clear opinion but I'm thinking
>> that warnings are better. A warning is still quite intrusive and
>> obvious. Maybe we don't need to decide this part now.
>
> The problem with warnings is that they can go unnoticed, unless
> followed by sit-for.

Eli, Paul,

Attached is test code for some of the scenarios we are discussing here.

My FSF papers are out of date. Mind sending me new ones?  I am in the
United States.

These tests operate by constructing buffers within directories that the
test then restricts permissions on, which induces errors from the varous
locking calls.  Each test is a FIXME that allows us to verify the
behavior change as work on bug#46397 progresses.

In doing this I discovered that Emacs silently ignores some IO errors
when constructing lock files.  Paul noticed this a while back and added
FIXME.  This patch adds a test with a corresponding FIXME.

The test isn't complete.  It relies on POSIX semantics from the
filesystem.  It might fail on Windows.  As the review progresses I can
work on handling that scenario more gracefully.

If this kind of a test is a bad idea, feel free to let me know.  I like
to have test coverage before I do code surgery, but I don't have strong
opinions here.


--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
 filename=0001-Add-some-test-coverage-for-src-filelock.c-Bug-46397.patch
Content-Description: add test coverage

From 99577c5a0b582e6d0c3d9fd495dec9f27d0cb7a2 Mon Sep 17 00:00:00 2001
From: Matt Armstrong <matt@HIDDEN>
Date: Mon, 15 Feb 2021 12:59:08 -0800
Subject: [PATCH] Add some test coverage for src/filelock.c (Bug#46397).

* test/src/filelock-tests.el: new file
---
 test/src/filelock-tests.el | 115 +++++++++++++++++++++++++++++++++++++
 1 file changed, 115 insertions(+)
 create mode 100644 test/src/filelock-tests.el

diff --git a/test/src/filelock-tests.el b/test/src/filelock-tests.el
new file mode 100644
index 0000000000..8cdcec09e7
--- /dev/null
+++ b/test/src/filelock-tests.el
@@ -0,0 +1,115 @@
+;;; filelock-tests.el --- test file locking -*- lexical-binding: t; -*-
+
+;; Copyright (C) 2021  Free Software Foundation, Inc.
+
+;; This file is part of GNU Emacs.
+
+;; GNU Emacs is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+
+;; This file tests code in src/filelock.c and, to some extent, the
+;; related code in src/fileio.c.
+
+;;; Code:
+
+(require 'ert)
+
+(defun filelock-tests--call-with-fixture (body)
+  (let ((test-dir (make-temp-file "filelock-tests-" t)))
+    (unwind-protect
+        (let ((file-name (concat (file-name-as-directory test-dir))))
+          (with-temp-buffer
+            (setq-local buffer-file-name file-name)
+            (setq-local buffer-file-truename file-name)
+            (unwind-protect
+                (save-current-buffer
+                  (let ((create-lockfiles t))
+                    (funcall body)))
+              (set-buffer-modified-p nil))))
+      (delete-directory test-dir t nil))))
+
+(defmacro filelock-tests--with-fixture (&rest body)
+  "Create a test fixture and evaluate BODY there like `progn'.
+Create a temporary directory, then create a temporary buffer and
+set it the variable `buffer-file-name' and `buffer-file-truename'
+to it, let bind `create-lockfiles' to 't' and evaluate BODY."
+  (declare (indent 0))
+  `(filelock-tests--call-with-fixture
+    (lambda () ,@body)))
+
+(defun filelock-tests--call-with-directory-modes (modes body)
+  (let* ((dir (file-name-directory (buffer-file-name)))
+         (original-modes (file-modes dir)))
+    (set-file-modes dir modes)
+    (unwind-protect
+        (funcall body)
+      (set-file-modes dir original-modes))))
+
+(defmacro filelock-tests--with-directory-modes (modes &rest body)
+  "Evaluate BODY forms with directory MODES set.
+The directory is taken from the buffer local variable
+`buffer-file-name'.  Afterwards, restore the modes to what they
+were."
+  (declare (indent 1))
+  `(filelock-tests--call-with-directory-modes
+    ,modes (lambda () ,@body)))
+
+(ert-deftest filelock-tests-lock-buffer-permission-denied ()
+  "Check that locking a buffer in a directory with no write
+permissions does not work."
+  (filelock-tests--with-fixture
+      (should (not (file-locked-p (buffer-file-name))))
+     (filelock-tests--with-directory-modes #o500
+       ;; FIXME: (lock-buffer) should raise some sort of
+       ;; error/warning here that we should verify in test.
+       ;; Currently lock_file() ignores errors from lock_if_free().
+       ;; See the related FIXME in filelock.c.
+       (lock-buffer)
+       (should (not (file-locked-p (buffer-file-name)))))))
+
+(ert-deftest filelock-tests-file-locked-p-permission-denied ()
+  "Check that `file-locked-p' fails if the directory is inaccesible."
+  (filelock-tests--with-fixture
+    (filelock-tests--with-directory-modes #o000
+      (set-buffer-modified-p t)
+      ;; FIXME: Bug#46397: `file-locked-p' currently signals errors,
+      ;; but this prevents the user from killing the buffer.  It also
+      ;; prevents Emacs shutdown.
+      (should
+       (equal
+        (butlast (should-error (file-locked-p (buffer-file-name)))
+                 2)
+        '(file-error "Testing file lock"))))))
+
+(ert-deftest filelock-tests-unlock-permission-denied ()
+  "Check that `unlock-buffer' fails in directories that cannot be
+modified."
+  (filelock-tests--with-fixture
+    (set-buffer-modified-p t)
+    (lock-buffer)
+    (should (file-locked-p (buffer-file-name)))
+    (filelock-tests--with-directory-modes #o500
+      ;; FIXME: Bug#46397: `unlock-buffer' currently signals errors,
+      ;; but this prevents the user from killing the buffer.  It also
+      ;; prevents Emacs shutdown.
+      (should
+       (equal
+        (butlast (should-error (unlock-buffer))
+                 2)
+        '(file-error "Unlocking file"))))))
+
+(provide 'filelock-tests)
+
+;;; filelock-tests.el ends here
-- 
2.30.0


--=-=-=--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 15 Feb 2021 15:09:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 15 10:09:57 2021
Received: from localhost ([127.0.0.1]:38480 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lBfVd-0002tP-46
	for submit <at> debbugs.gnu.org; Mon, 15 Feb 2021 10:09:57 -0500
Received: from eggs.gnu.org ([209.51.188.92]:39858)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lBfVX-0002t9-JK
 for 46397 <at> debbugs.gnu.org; Mon, 15 Feb 2021 10:09:56 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:58749)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lBfVS-000451-Ds; Mon, 15 Feb 2021 10:09:46 -0500
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3810
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1lBfVR-0007Cz-Mm; Mon, 15 Feb 2021 10:09:46 -0500
Date: Mon, 15 Feb 2021 17:09:48 +0200
Message-Id: <83wnv99xkz.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Matt Armstrong <gmatta@HIDDEN>
In-Reply-To: <m24kie8fdf.fsf@HIDDEN> (message from Matt Armstrong
 on Sun, 14 Feb 2021 14:16:12 -0800)
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
 <m2blcskbyq.fsf@HIDDEN> <83a6scj745.fsf@HIDDEN>
 <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN>
 <m2blcqckv7.fsf@HIDDEN>
 <f7079852-58f6-1eb4-9d68-35251c1938ff@HIDDEN>
 <83tuqhg3j9.fsf@HIDDEN> <m2wnvcahtt.fsf@HIDDEN>
 <83czx4e5h5.fsf@HIDDEN> <m2v9av8od4.fsf@HIDDEN>
 <83zh06a1yv.fsf@HIDDEN> <m24kie8fdf.fsf@HIDDEN>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 46397
Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> From: Matt Armstrong <gmatta@HIDDEN>
> Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
> Date: Sun, 14 Feb 2021 14:16:12 -0800
> 
> When releasing the lock, I have a less clear opinion but I'm thinking
> that warnings are better. A warning is still quite intrusive and
> obvious. Maybe we don't need to decide this part now.

The problem with warnings is that they can go unnoticed, unless
followed by sit-for.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 14 Feb 2021 22:16:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 14 17:16:27 2021
Received: from localhost ([127.0.0.1]:36930 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lBPgo-0004rV-W0
	for submit <at> debbugs.gnu.org; Sun, 14 Feb 2021 17:16:27 -0500
Received: from relay11.mail.gandi.net ([217.70.178.231]:51867)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gmatta@HIDDEN>) id 1lBPgm-0004r2-Rb
 for 46397 <at> debbugs.gnu.org; Sun, 14 Feb 2021 17:16:25 -0500
Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com
 [24.113.169.116]) (Authenticated sender: matt@HIDDEN)
 by relay11.mail.gandi.net (Postfix) with ESMTPSA id 84A30100003;
 Sun, 14 Feb 2021 22:16:15 +0000 (UTC)
From: Matt Armstrong <gmatta@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
In-Reply-To: <83zh06a1yv.fsf@HIDDEN>
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
 <m2blcskbyq.fsf@HIDDEN> <83a6scj745.fsf@HIDDEN>
 <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN>
 <m2blcqckv7.fsf@HIDDEN>
 <f7079852-58f6-1eb4-9d68-35251c1938ff@HIDDEN>
 <83tuqhg3j9.fsf@HIDDEN> <m2wnvcahtt.fsf@HIDDEN>
 <83czx4e5h5.fsf@HIDDEN> <m2v9av8od4.fsf@HIDDEN>
 <83zh06a1yv.fsf@HIDDEN>
Date: Sun, 14 Feb 2021 14:16:12 -0800
Message-ID: <m24kie8fdf.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 2.3 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: Eli Zaretskii writes: >> From: Matt Armstrong >> Cc:
 46397 <at> debbugs.gnu.org, 
 eggert@HIDDEN, craven@HIDDEN >> Date: Sat, 13 Feb 2021 16:49:43 -0800
 >> >> I think auto-save issues messages and warnings, but never prom [...]
 Content analysis details:   (2.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [217.70.178.231 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
 [217.70.178.231 listed in wl.mailspike.net]
 1.0 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)
 1.0 FORGED_GMAIL_RCVD      'From' gmail.com does not match 'Received'
 headers
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (gmatta[at]gmail.com)
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
 1.0 FREEMAIL_REPLY         From and body contain different freemails
X-Debbugs-Envelope-To: 46397
Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: Matt Armstrong <gmatta@HIDDEN>
>> Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
>> Date: Sat, 13 Feb 2021 16:49:43 -0800
>> 
>> I think auto-save issues messages and warnings, but never prompts
>> ("asks about").
>> 
>> Auto save can call `display-warning' (see auto_save_error in
>> fileio.c) or `message' (see message1() and message_with_string()
>> calls in same). I can't find any prompts.
>> 
>> So let's settle a question before going further. Would you be okay if
>> lock errors were reported in the same way(s) auto-save errors are?
>
> I'm okay with doing the same as auto-save does when Emacs is shutting
> down, yes.  As for other situations, I'm not sure we should just
> display a warning.
>
> Were you asking only about what to do during shutdown?

I have been primarily worried about shutdown, yes.

For non-shutdown, I want to consider errors acquiring and releasing the
lock separately.

When acquiring the lock, I think a prompt is good. The user interaction
I imagine is similar to 'ask-user-about-lock' (steal/proceed/quit), but
might just be (proceed/quit).

When releasing the lock, I have a less clear opinion but I'm thinking
that warnings are better. A warning is still quite intrusive and
obvious. Maybe we don't need to decide this part now.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 14 Feb 2021 19:22:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 14 14:22:56 2021
Received: from localhost ([127.0.0.1]:36763 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lBMyu-0004ZS-IZ
	for submit <at> debbugs.gnu.org; Sun, 14 Feb 2021 14:22:56 -0500
Received: from eggs.gnu.org ([209.51.188.92]:34092)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lBMys-0004ZF-Q2
 for 46397 <at> debbugs.gnu.org; Sun, 14 Feb 2021 14:22:55 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:43764)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lBMym-0007O8-Tu; Sun, 14 Feb 2021 14:22:48 -0500
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2544
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1lBMyl-0003Z2-3P; Sun, 14 Feb 2021 14:22:48 -0500
Date: Sun, 14 Feb 2021 21:22:48 +0200
Message-Id: <83zh06a1yv.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Matt Armstrong <gmatta@HIDDEN>
In-Reply-To: <m2v9av8od4.fsf@HIDDEN> (message from Matt Armstrong
 on Sat, 13 Feb 2021 16:49:43 -0800)
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
 <m2blcskbyq.fsf@HIDDEN> <83a6scj745.fsf@HIDDEN>
 <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN>
 <m2blcqckv7.fsf@HIDDEN>
 <f7079852-58f6-1eb4-9d68-35251c1938ff@HIDDEN>
 <83tuqhg3j9.fsf@HIDDEN> <m2wnvcahtt.fsf@HIDDEN>
 <83czx4e5h5.fsf@HIDDEN> <m2v9av8od4.fsf@HIDDEN>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 46397
Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> From: Matt Armstrong <gmatta@HIDDEN>
> Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
> Date: Sat, 13 Feb 2021 16:49:43 -0800
> 
> I think auto-save issues messages and warnings, but never prompts ("asks
> about").
> 
> Auto save can call `display-warning' (see auto_save_error in fileio.c)
> or `message' (see message1() and message_with_string() calls in same). I
> can't find any prompts.
> 
> So let's settle a question before going further. Would you be okay if
> lock errors were reported in the same way(s) auto-save errors are?

I'm okay with doing the same as auto-save does when Emacs is shutting
down, yes.  As for other situations, I'm not sure we should just
display a warning.

Were you asking only about what to do during shutdown?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 14 Feb 2021 00:49:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 13 19:49:58 2021
Received: from localhost ([127.0.0.1]:35253 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lB5bp-0002Gs-Vk
	for submit <at> debbugs.gnu.org; Sat, 13 Feb 2021 19:49:58 -0500
Received: from relay2-d.mail.gandi.net ([217.70.183.194]:57171)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gmatta@HIDDEN>) id 1lB5bo-0002GX-Do
 for 46397 <at> debbugs.gnu.org; Sat, 13 Feb 2021 19:49:57 -0500
X-Originating-IP: 24.113.169.116
Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com
 [24.113.169.116]) (Authenticated sender: matt@HIDDEN)
 by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id AAA1840003;
 Sun, 14 Feb 2021 00:49:47 +0000 (UTC)
From: Matt Armstrong <gmatta@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
In-Reply-To: <83czx4e5h5.fsf@HIDDEN>
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
 <m2blcskbyq.fsf@HIDDEN> <83a6scj745.fsf@HIDDEN>
 <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN>
 <m2blcqckv7.fsf@HIDDEN>
 <f7079852-58f6-1eb4-9d68-35251c1938ff@HIDDEN>
 <83tuqhg3j9.fsf@HIDDEN> <m2wnvcahtt.fsf@HIDDEN>
 <83czx4e5h5.fsf@HIDDEN>
Date: Sat, 13 Feb 2021 16:49:43 -0800
Message-ID: <m2v9av8od4.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: Eli Zaretskii writes: >> There is also the case where
 'kill_emacs'
 is called from a signal, >> which [...] > But we do ask about auto-save errors
 in these cases, don't we? If so, > why not ask about locks as well? 
 Content analysis details:   (1.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [217.70.183.194 listed in list.dnswl.org]
 0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
 [217.70.183.194 listed in wl.mailspike.net]
 1.0 FORGED_GMAIL_RCVD      'From' gmail.com does not match 'Received'
 headers
 1.0 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (gmatta[at]gmail.com)
 0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
X-Debbugs-Envelope-To: 46397
Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

Eli Zaretskii <eliz@HIDDEN> writes:

>> There is also the case where 'kill_emacs' is called from a signal,
>> which
[...]
> But we do ask about auto-save errors in these cases, don't we?  If so,
> why not ask about locks as well?

I think auto-save issues messages and warnings, but never prompts ("asks
about").

Auto save can call `display-warning' (see auto_save_error in fileio.c)
or `message' (see message1() and message_with_string() calls in same). I
can't find any prompts.

So let's settle a question before going further. Would you be okay if
lock errors were reported in the same way(s) auto-save errors are?

I should reveal: during shut down, both `message' and `display-warning'
seems to have no effect. The first thing `shut_down_emacs()' does is
inhibit display, which is probably why.

Taking this approach would be a tremendous simplification over what I
had been thiking you were asking for. Most of my confusion centers
around re-aranging code flow such that all possible errors occur, by
construction, only *before* shut_down_emacs() may be called.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 13 Feb 2021 08:29:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 13 03:29:07 2021
Received: from localhost ([127.0.0.1]:33522 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lAqIc-00037u-MK
	for submit <at> debbugs.gnu.org; Sat, 13 Feb 2021 03:29:06 -0500
Received: from eggs.gnu.org ([209.51.188.92]:42748)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lAqIa-00037M-RO
 for 46397 <at> debbugs.gnu.org; Sat, 13 Feb 2021 03:29:05 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:45302)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lAqIU-00043o-QX; Sat, 13 Feb 2021 03:28:58 -0500
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3816
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1lAqIR-0004RR-OK; Sat, 13 Feb 2021 03:28:56 -0500
Date: Sat, 13 Feb 2021 10:28:54 +0200
Message-Id: <83czx4e5h5.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Matt Armstrong <gmatta@HIDDEN>
In-Reply-To: <m2wnvcahtt.fsf@HIDDEN> (message from Matt Armstrong
 on Fri, 12 Feb 2021 17:15:42 -0800)
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
 <m2blcskbyq.fsf@HIDDEN> <83a6scj745.fsf@HIDDEN>
 <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN>
 <m2blcqckv7.fsf@HIDDEN>
 <f7079852-58f6-1eb4-9d68-35251c1938ff@HIDDEN>
 <83tuqhg3j9.fsf@HIDDEN> <m2wnvcahtt.fsf@HIDDEN>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 46397
Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> From: Matt Armstrong <gmatta@HIDDEN>
> Cc: 46397 <at> debbugs.gnu.org, craven@HIDDEN
> Date: Fri, 12 Feb 2021 17:15:42 -0800
> 
> One obvious issue is my inexperience in the code base. The locking logic
> all seems handled in C code, and I'm not yet very familiar with Emacs'
> particularities. Most of my multi-decade long career has been in lower
> level C++ code, so it is semi-familiar, but I haven't yet internalized
> how to think about problems in the Emacs lispy-way. I keep grasping for
> expressions of OO ideas that just aren't there, or at least aren't clear
> to me. :)

Feel free to ask questions about the internals.

> One issue is that 'unlock_file' has about 10 callers (though over half
> are from write-region).
> 
> I'm not sure how functions like 'write_region',
> 'restore-buffer-modified-p' and 'replace-buffer-contents' should be
> handling lock and unlock failures.

Why not in a unified manner?  IOW, define a single function to handle
the situation where unlocking triggers some error from lower-level
APIs such as 'unlink', and call it from unlock_file no matter what was
its caller?

> I think save-buffers-kill-terminal should be modified to leave the
> buffers in a state that won't trigger un-locking much later (after it is
> too late to do proper UI interactions). If a user opts to not save a
> buffer, then the unlock could happen immediately (and possibly surface
> an error of its own). Sound good?

I don't think I understand what you are proposing here in enough
detail.  You seem to be describing several issues together, and I
don't think I understand how you propose to solve each one of them.

> One problem with the above: currently buffers do not track whether Emacs
> thinks they hold the lock. Normally I'd think about adding a "user chose
> to ignore unlock errors" flag at that spot, but it doesn't exist.

Why would we need such a flag?  Can you show a couple of use cases
where it would be necessary?

> Instead, code attempts to re-verify lock state from the file system at
> every operation. Not even setting `create-lockfiles' to nil is enough to
> prevent Emacs from attempting to delete them. Some mechanism to record
> the user's desire to bypass lock file errors is needed.

Why is such an option needed?  If we can reasonably deal with failures
to unlock each file, wouldn't that be enough?

> There is also the case where 'kill_emacs' is called from a signal, which
> seems to proceed directly to shutdown without prompting the user to save
> buffers. For this flow, I think the only option is to "swallow" the
> errors while unlocking files. The Emacs manually even allows or this
> possibility (mentioning "if Emacs crashes..."). Sound good?

But we do ask about auto-save errors in these cases, don't we?  If so,
why not ask about locks as well?

Thanks for working on this.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 13 Feb 2021 08:21:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 13 03:21:26 2021
Received: from localhost ([127.0.0.1]:33518 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lAqBB-0002x6-SR
	for submit <at> debbugs.gnu.org; Sat, 13 Feb 2021 03:21:26 -0500
Received: from eggs.gnu.org ([209.51.188.92]:41860)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lAqBA-0002wu-CY
 for 46397 <at> debbugs.gnu.org; Sat, 13 Feb 2021 03:21:25 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:45245)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lAqB4-0000eu-Pd; Sat, 13 Feb 2021 03:21:18 -0500
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3347
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1lAqB4-0003YZ-7O; Sat, 13 Feb 2021 03:21:18 -0500
Date: Sat, 13 Feb 2021 10:21:15 +0200
Message-Id: <83eehke5tw.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-Reply-To: <3b63c6d1-4709-f9e3-6914-2f498ef8a970@HIDDEN> (message from
 Paul Eggert on Fri, 12 Feb 2021 17:26:00 -0800)
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
 <m2blcskbyq.fsf@HIDDEN> <83a6scj745.fsf@HIDDEN>
 <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN>
 <m2blcqckv7.fsf@HIDDEN>
 <f7079852-58f6-1eb4-9d68-35251c1938ff@HIDDEN> <83tuqhg3j9.fsf@HIDDEN>
 <m2wnvcahtt.fsf@HIDDEN>
 <3b63c6d1-4709-f9e3-6914-2f498ef8a970@HIDDEN>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 46397
Cc: gmatta@HIDDEN, 46397 <at> debbugs.gnu.org, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> Cc: 46397 <at> debbugs.gnu.org, craven@HIDDEN
> From: Paul Eggert <eggert@HIDDEN>
> Date: Fri, 12 Feb 2021 17:26:00 -0800
> 
> On 2/12/21 5:15 PM, Matt Armstrong wrote:
> > You have suggested showing a prompt. What question would it ask?
> 
> How about this:
> 
> /tmp/x/y lock is invalid; assume unlocked? (yes or no)

Yes, SGTM.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 13 Feb 2021 08:07:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 13 03:07:55 2021
Received: from localhost ([127.0.0.1]:33508 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lApy6-0002cB-CU
	for submit <at> debbugs.gnu.org; Sat, 13 Feb 2021 03:07:55 -0500
Received: from eggs.gnu.org ([209.51.188.92]:40538)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lApy4-0002by-Ix
 for 46397 <at> debbugs.gnu.org; Sat, 13 Feb 2021 03:07:52 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:45155)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lApxy-0002ss-4n; Sat, 13 Feb 2021 03:07:46 -0500
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2520
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1lApxx-00045H-HK; Sat, 13 Feb 2021 03:07:45 -0500
Date: Sat, 13 Feb 2021 10:07:44 +0200
Message-Id: <83h7mge6gf.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Matt Armstrong <gmatta@HIDDEN>
In-Reply-To: <m2wnvcalcj.fsf@HIDDEN> (message from Matt Armstrong
 on Fri, 12 Feb 2021 15:59:40 -0800)
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
 <m2blcskbyq.fsf@HIDDEN> <83a6scj745.fsf@HIDDEN>
 <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN>
 <835z2ziu52.fsf@HIDDEN> <m25z2zfsyf.fsf@HIDDEN>
 <83pn15g28y.fsf@HIDDEN>
 <2ce4897b-56ac-9409-b5e8-c735528e48f1@HIDDEN>
 <83ft21frma.fsf@HIDDEN> <m2wnvcalcj.fsf@HIDDEN>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 46397
Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> From: Matt Armstrong <gmatta@HIDDEN>
> Cc: 46397 <at> debbugs.gnu.org, craven@HIDDEN
> Date: Fri, 12 Feb 2021 15:59:40 -0800
> 
> > Nobody owns the lock _now_, but how did that come to happen?  We have
> > no idea.  It could be an indication that the user's files are under
> > attack, for example.  So silently assuming that the lock doesn't exist
> > is not necessarily TRT.
> 
> I think this portion of the discussion is on the fringe of the important
> issue.

For me, it _is_ the important issue.  This bug is just an indication
of a larger problem we have.

> Right now, 'current_lock_owner' can return arbitrary errno
> values, and if it does Emacs is in a bad situation:
> 
>  a) The user can't kill the buffer interactively.
>  b) Emacs can't exit, gets in a bad state, and must be killed.
> 
> So, definitely, we need to fix that.

So let's fix that instead of arguing, okay?

> Separately, I continue to think Paul's recent commit is fine.

I beg to differ: by solving that single aspect of a larger problem, it
makes the larger problem less urgent, and that runs high risk of
leaving it unsolved, IME.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 13 Feb 2021 01:26:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 12 20:26:56 2021
Received: from localhost ([127.0.0.1]:33260 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lAjhp-0007cY-Gm
	for submit <at> debbugs.gnu.org; Fri, 12 Feb 2021 20:26:56 -0500
Received: from [131.179.128.68] (port=37068 helo=zimbra.cs.ucla.edu)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1lAjhT-0007br-Cw
 for 46397 <at> debbugs.gnu.org; Fri, 12 Feb 2021 20:26:34 -0500
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id A804C160115;
 Fri, 12 Feb 2021 17:26:01 -0800 (PST)
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 KAlcpStRtOMs; Fri, 12 Feb 2021 17:26:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 08C3F160109;
 Fri, 12 Feb 2021 17:26:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
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 6yRth0Jxrdxf; Fri, 12 Feb 2021 17:26:00 -0800 (PST)
Received: from [192.168.1.9] (cpe-23-243-218-95.socal.res.rr.com
 [23.243.218.95])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id D194C160108;
 Fri, 12 Feb 2021 17:26:00 -0800 (PST)
To: Matt Armstrong <gmatta@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
 <m2blcskbyq.fsf@HIDDEN> <83a6scj745.fsf@HIDDEN>
 <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN>
 <m2blcqckv7.fsf@HIDDEN>
 <f7079852-58f6-1eb4-9d68-35251c1938ff@HIDDEN> <83tuqhg3j9.fsf@HIDDEN>
 <m2wnvcahtt.fsf@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
Message-ID: <3b63c6d1-4709-f9e3-6914-2f498ef8a970@HIDDEN>
Date: Fri, 12 Feb 2021 17:26:00 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <m2wnvcahtt.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  On 2/12/21 5:15 PM,
 Matt Armstrong wrote: > You have suggested
 showing a prompt. What question would it ask? How about this: /tmp/x/y lock
 is invalid; assume unlocked? (yes or no) 
 Content analysis details:   (1.2 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.0 T_SPF_HELO_TEMPERROR   SPF: test of HELO record failed (temperror)
 0.0 T_SPF_TEMPERROR        SPF: test of record failed (temperror)
 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS
 -0.1 NICE_REPLY_A           Looks like a legit reply (A)
X-Debbugs-Envelope-To: 46397
Cc: 46397 <at> debbugs.gnu.org, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)

On 2/12/21 5:15 PM, Matt Armstrong wrote:
> You have suggested showing a prompt. What question would it ask?

How about this:

/tmp/x/y lock is invalid; assume unlocked? (yes or no)





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 13 Feb 2021 01:16:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 12 20:16:39 2021
Received: from localhost ([127.0.0.1]:33254 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lAjXs-0007Nt-LM
	for submit <at> debbugs.gnu.org; Fri, 12 Feb 2021 20:16:39 -0500
Received: from relay10.mail.gandi.net ([217.70.178.230]:41631)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gmatta@HIDDEN>) id 1lAjXX-0007Mw-1G
 for 46397 <at> debbugs.gnu.org; Fri, 12 Feb 2021 20:16:18 -0500
Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com
 [24.113.169.116]) (Authenticated sender: matt@HIDDEN)
 by relay10.mail.gandi.net (Postfix) with ESMTPSA id E3C16240002;
 Sat, 13 Feb 2021 01:15:45 +0000 (UTC)
From: Matt Armstrong <gmatta@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>, Paul Eggert <eggert@HIDDEN>
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
In-Reply-To: <83tuqhg3j9.fsf@HIDDEN>
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
 <m2blcskbyq.fsf@HIDDEN> <83a6scj745.fsf@HIDDEN>
 <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN>
 <m2blcqckv7.fsf@HIDDEN>
 <f7079852-58f6-1eb4-9d68-35251c1938ff@HIDDEN>
 <83tuqhg3j9.fsf@HIDDEN>
Date: Fri, 12 Feb 2021 17:15:42 -0800
Message-ID: <m2wnvcahtt.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 2.0 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  Eli Zaretskii writes: >> Cc: 46397 <at> debbugs.gnu.org,
 craven@HIDDEN
 >> From: Paul Eggert >> Date: Thu, 11 Feb 2021 18:20:44 -0800 >> >> On 2/11/21
 2:14 PM, Matt Armstrong wrote: >> >> > The issue isn't confined to exiting
 [...] Content analysis details:   (2.0 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (gmatta[at]gmail.com)
 0.0 T_SPF_HELO_TEMPERROR   SPF: test of HELO record failed (temperror)
 1.0 FORGED_GMAIL_RCVD      'From' gmail.com does not match 'Received'
 headers
 0.0 T_SPF_TEMPERROR        SPF: test of record failed (temperror)
 1.0 FREEMAIL_REPLY         From and body contain different freemails
X-Debbugs-Envelope-To: 46397
Cc: 46397 <at> debbugs.gnu.org, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

Eli Zaretskii <eliz@HIDDEN> writes:

>> Cc: 46397 <at> debbugs.gnu.org, craven@HIDDEN
>> From: Paul Eggert <eggert@HIDDEN>
>> Date: Thu, 11 Feb 2021 18:20:44 -0800
>> 
>> On 2/11/21 2:14 PM, Matt Armstrong wrote:
>> 
>> > The issue isn't confined to exiting Emacs. It appears that once in a
>> > "tricky situation where the file can't be unlocked for whatever reason"
>> > Emacs will refuse to kill the buffer because unlock_file() signals an
>> > error.
>> 
>> kill-buffer already asks the user something like "Buffer XXX modified; 
>> kill anyway? (yes or no)" when killing a buffer that's been changed 
>> without being saved. Perhaps it should also ask "File XXX cannot be 
>> unlocked; kill buffer anyway? (yes or no)" if the file can't be unlocked.
>> 
>> > Note that shut_down_emacs() calls Fdo_auto_save() just before
>> > unlock_all_files() and that call succeeds. Fdo_auto_save() also calls
>> > report_file_errno, throwing an errno 13 (Permission denied), but that
>> > recovers and continues.
>> 
>> Presumably shut_down_emacs should recover and continue if 
>> unlock_all_files fails when it directly calls unlock_all_files.
>
> That all is true, but I think we should provide for recovery in a way
> that will work with _any_ command that calls unlock_file or
> unlock_all_files.  Not just these two instances.  See my other message
> about this.

Eli, I looked a bit at finding a general solution.

One obvious issue is my inexperience in the code base. The locking logic
all seems handled in C code, and I'm not yet very familiar with Emacs'
particularities. Most of my multi-decade long career has been in lower
level C++ code, so it is semi-familiar, but I haven't yet internalized
how to think about problems in the Emacs lispy-way. I keep grasping for
expressions of OO ideas that just aren't there, or at least aren't clear
to me. :)

One issue is that 'unlock_file' has about 10 callers (though over half
are from write-region).

I'm not sure how functions like 'write_region',
'restore-buffer-modified-p' and 'replace-buffer-contents' should be
handling lock and unlock failures.

I think save-buffers-kill-terminal should be modified to leave the
buffers in a state that won't trigger un-locking much later (after it is
too late to do proper UI interactions). If a user opts to not save a
buffer, then the unlock could happen immediately (and possibly surface
an error of its own). Sound good?

One problem with the above: currently buffers do not track whether Emacs
thinks they hold the lock. Normally I'd think about adding a "user chose
to ignore unlock errors" flag at that spot, but it doesn't exist.

Instead, code attempts to re-verify lock state from the file system at
every operation. Not even setting `create-lockfiles' to nil is enough to
prevent Emacs from attempting to delete them. Some mechanism to record
the user's desire to bypass lock file errors is needed.

There is also the case where 'kill_emacs' is called from a signal, which
seems to proceed directly to shutdown without prompting the user to save
buffers. For this flow, I think the only option is to "swallow" the
errors while unlocking files. The Emacs manually even allows or this
possibility (mentioning "if Emacs crashes..."). Sound good?

You have suggested showing a prompt. What question would it ask? I am
having trouble imagining ways of making the situation clear to the user.
There are also many situations:

 - unable to determine if Emacs has the lock
 - unable to acquire the lock
 - unable to release the lock

None of these are questions. What do we expect the user to actually
understand and answer to from these prompts? Or, is issuing a message
sufficient? A message would certainly simplify things.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 12 Feb 2021 23:59:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 12 18:59:56 2021
Received: from localhost ([127.0.0.1]:33210 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lAiLr-0005OU-TZ
	for submit <at> debbugs.gnu.org; Fri, 12 Feb 2021 18:59:56 -0500
Received: from relay8-d.mail.gandi.net ([217.70.183.201]:55403)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gmatta@HIDDEN>) id 1lAiLp-0005OE-0p
 for 46397 <at> debbugs.gnu.org; Fri, 12 Feb 2021 18:59:55 -0500
X-Originating-IP: 24.113.169.116
Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com
 [24.113.169.116]) (Authenticated sender: matt@HIDDEN)
 by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 4697E1BF203;
 Fri, 12 Feb 2021 23:59:43 +0000 (UTC)
From: Matt Armstrong <gmatta@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>, Paul Eggert <eggert@HIDDEN>
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
In-Reply-To: <83ft21frma.fsf@HIDDEN>
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
 <m2blcskbyq.fsf@HIDDEN> <83a6scj745.fsf@HIDDEN>
 <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN>
 <835z2ziu52.fsf@HIDDEN> <m25z2zfsyf.fsf@HIDDEN>
 <83pn15g28y.fsf@HIDDEN>
 <2ce4897b-56ac-9409-b5e8-c735528e48f1@HIDDEN>
 <83ft21frma.fsf@HIDDEN>
Date: Fri, 12 Feb 2021 15:59:40 -0800
Message-ID: <m2wnvcalcj.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 2.3 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  Eli Zaretskii writes: >> Cc: gmatta@HIDDEN,
 46397 <at> debbugs.gnu.org, 
 craven@HIDDEN, >> Matt Armstrong >> From: Paul Eggert >> Date: Fri, 12 Feb
 2021 01:36:30 -0800 >> >> > The Posix spec of 'unlink' says: >> >> Matt [...]
 Content analysis details:   (2.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (gmatta[at]gmail.com)
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [217.70.183.201 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
 [217.70.183.201 listed in wl.mailspike.net]
 1.0 FORGED_GMAIL_RCVD      'From' gmail.com does not match 'Received'
 headers
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 1.0 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)
 1.0 FREEMAIL_REPLY         From and body contain different freemails
X-Debbugs-Envelope-To: 46397
Cc: 46397 <at> debbugs.gnu.org, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

Eli Zaretskii <eliz@HIDDEN> writes:

>> Cc: gmatta@HIDDEN, 46397 <at> debbugs.gnu.org, craven@HIDDEN,
>>  Matt Armstrong <matt@HIDDEN>
>> From: Paul Eggert <eggert@HIDDEN>
>> Date: Fri, 12 Feb 2021 01:36:30 -0800
>> 
>> > The Posix spec of 'unlink' says:
>> 
>> Matt was talking about current_lock_owner, a function that does not call 
>> 'unlink', so it's not clear why the 'unlink' spec is relevant here.
>
> Is the description for other APIs significantly different?  If not,
> then this details is not important.
>
>> current_lock_owner eventually calls either readlinkat or (on systems 
>> without symlinks) openat. If either fails with ENOTDIR, some ancestor of 
>> the lock file is a non-directory, hence the lock file itself cannot 
>> possibly exist and therefore it must be the case that nobody owns the 
>> lock.
>
> Nobody owns the lock _now_, but how did that come to happen?  We have
> no idea.  It could be an indication that the user's files are under
> attack, for example.  So silently assuming that the lock doesn't exist
> is not necessarily TRT.

I think this portion of the discussion is on the fringe of the important
issue. Right now, 'current_lock_owner' can return arbitrary errno
values, and if it does Emacs is in a bad situation:

 a) The user can't kill the buffer interactively.
 b) Emacs can't exit, gets in a bad state, and must be killed.

So, definitely, we need to fix that.


Separately, I continue to think Paul's recent commit is fine. With due
consideration to the issue of inferring too much about system state
based on errno inspection, ENOTDIR and ENOENT are both unambiguously
specified for the functions 'current_lock_owner' calls -- to mean the
path components that should be directories are not in fact directories
-- and so both errno values imply that the lock file isn't at the path
Emacs is has associated with the buffer.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 12 Feb 2021 11:33:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 12 06:33:06 2021
Received: from localhost ([127.0.0.1]:60051 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lAWh8-0004Jj-JG
	for submit <at> debbugs.gnu.org; Fri, 12 Feb 2021 06:33:06 -0500
Received: from eggs.gnu.org ([209.51.188.92]:60198)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lAWh5-0004JB-JW
 for 46397 <at> debbugs.gnu.org; Fri, 12 Feb 2021 06:33:04 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:41124)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lAWgx-0003Up-Ro; Fri, 12 Feb 2021 06:32:57 -0500
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1898
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1lAWgx-0008Ti-7D; Fri, 12 Feb 2021 06:32:55 -0500
Date: Fri, 12 Feb 2021 13:33:01 +0200
Message-Id: <83ft21frma.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-Reply-To: <2ce4897b-56ac-9409-b5e8-c735528e48f1@HIDDEN> (message from
 Paul Eggert on Fri, 12 Feb 2021 01:36:30 -0800)
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
 <m2blcskbyq.fsf@HIDDEN> <83a6scj745.fsf@HIDDEN>
 <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN> <835z2ziu52.fsf@HIDDEN>
 <m25z2zfsyf.fsf@HIDDEN> <83pn15g28y.fsf@HIDDEN>
 <2ce4897b-56ac-9409-b5e8-c735528e48f1@HIDDEN>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 46397
Cc: gmatta@HIDDEN, 46397 <at> debbugs.gnu.org, craven@HIDDEN, matt@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> Cc: gmatta@HIDDEN, 46397 <at> debbugs.gnu.org, craven@HIDDEN,
>  Matt Armstrong <matt@HIDDEN>
> From: Paul Eggert <eggert@HIDDEN>
> Date: Fri, 12 Feb 2021 01:36:30 -0800
> 
> > The Posix spec of 'unlink' says:
> 
> Matt was talking about current_lock_owner, a function that does not call 
> 'unlink', so it's not clear why the 'unlink' spec is relevant here.

Is the description for other APIs significantly different?  If not,
then this details is not important.

> current_lock_owner eventually calls either readlinkat or (on systems 
> without symlinks) openat. If either fails with ENOTDIR, some ancestor of 
> the lock file is a non-directory, hence the lock file itself cannot 
> possibly exist and therefore it must be the case that nobody owns the 
> lock.

Nobody owns the lock _now_, but how did that come to happen?  We have
no idea.  It could be an indication that the user's files are under
attack, for example.  So silently assuming that the lock doesn't exist
is not necessarily TRT.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 12 Feb 2021 09:36:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 12 04:36:40 2021
Received: from localhost ([127.0.0.1]:59922 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lAUsR-0007dp-VO
	for submit <at> debbugs.gnu.org; Fri, 12 Feb 2021 04:36:40 -0500
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:44436)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1lAUsP-0007da-DA
 for 46397 <at> debbugs.gnu.org; Fri, 12 Feb 2021 04:36:38 -0500
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5C923160054;
 Fri, 12 Feb 2021 01:36:31 -0800 (PST)
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 baHUaAZ4HwAP; Fri, 12 Feb 2021 01:36:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9550D1600FE;
 Fri, 12 Feb 2021 01:36:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
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 vTs4D2b7K2Wn; Fri, 12 Feb 2021 01:36:30 -0800 (PST)
Received: from [192.168.1.9] (cpe-23-243-218-95.socal.res.rr.com
 [23.243.218.95])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 66834160054;
 Fri, 12 Feb 2021 01:36:30 -0800 (PST)
To: Eli Zaretskii <eliz@HIDDEN>
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
 <m2blcskbyq.fsf@HIDDEN> <83a6scj745.fsf@HIDDEN>
 <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN> <835z2ziu52.fsf@HIDDEN>
 <m25z2zfsyf.fsf@HIDDEN> <83pn15g28y.fsf@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
Message-ID: <2ce4897b-56ac-9409-b5e8-c735528e48f1@HIDDEN>
Date: Fri, 12 Feb 2021 01:36:30 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <83pn15g28y.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.8 (/)
X-Debbugs-Envelope-To: 46397
Cc: gmatta@HIDDEN, 46397 <at> debbugs.gnu.org, craven@HIDDEN,
 Matt Armstrong <matt@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.8 (-)

On 2/11/21 11:43 PM, Eli Zaretskii wrote:
>> From: Matt Armstrong <matt@HIDDEN>

>> In this case, Paul's commit changes the current_lock_owner() function
>> such that it returns zero upon ENOTDIR. The caller must interpret the
>> zero return as meaning "at the time current_lock_owner() was called,
>> nobody owned the lock file...or the lock file was obsolete."
>>
>> ENOTDIR has a specific meaning that we can rely on. Both ENOENT and
>> ENOTDIR imply that the file was definitely not on disk at the time of
>> the call. Because of this, current_lock_owner() can safely conclude th=
at
>> nobody owned the lock.
>=20
> "Definitely"? "safely"?  How do you arrive at that conclusion?
>=20
> The Posix spec of 'unlink' says:

Matt was talking about current_lock_owner, a function that does not call=20
'unlink', so it's not clear why the 'unlink' spec is relevant here.

current_lock_owner eventually calls either readlinkat or (on systems=20
without symlinks) openat. If either fails with ENOTDIR, some ancestor of=20
the lock file is a non-directory, hence the lock file itself cannot=20
possibly exist and therefore it must be the case that nobody owns the=20
lock. This is true regardless of which particular ancestor is a=20
non-directory. (The lockfile name does not end in "/", so we needn't=20
worry about that case here.)




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 12 Feb 2021 07:43:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 12 02:43:30 2021
Received: from localhost ([127.0.0.1]:59856 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lAT6w-00052n-EA
	for submit <at> debbugs.gnu.org; Fri, 12 Feb 2021 02:43:30 -0500
Received: from eggs.gnu.org ([209.51.188.92]:45036)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lAT6u-00052Z-WF
 for 46397 <at> debbugs.gnu.org; Fri, 12 Feb 2021 02:43:29 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:32857)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lAT6n-00030w-M7; Fri, 12 Feb 2021 02:43:21 -0500
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3440
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1lAT6n-0006Vf-5A; Fri, 12 Feb 2021 02:43:21 -0500
Date: Fri, 12 Feb 2021 09:43:25 +0200
Message-Id: <83pn15g28y.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Matt Armstrong <matt@HIDDEN>
In-Reply-To: <m25z2zfsyf.fsf@HIDDEN> (message from Matt Armstrong
 on Wed, 10 Feb 2021 14:39:36 -0800)
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
 <m2blcskbyq.fsf@HIDDEN> <83a6scj745.fsf@HIDDEN>
 <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN>
 <835z2ziu52.fsf@HIDDEN> <m25z2zfsyf.fsf@HIDDEN>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 46397
Cc: gmatta@HIDDEN, 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> From: Matt Armstrong <matt@HIDDEN>
> Cc: Paul Eggert <eggert@HIDDEN>,  gmatta@HIDDEN,
>   46397 <at> debbugs.gnu.org,  craven@HIDDEN
> Date: Wed, 10 Feb 2021 14:39:36 -0800
> 
> > We should not ignore these errors, we should ask the user what to do
> > about them.  The user can tell us the error can be ignored, but we
> > should not decide that without asking.
> 
> I think Paul's commit is a good one. I'll try to explain why.
> 
> The commit does not silently ignore ENOTDIR. Instead, it is explicitly
> handles that particular error code it in a way that honors the lock file
> API contract.

I said "silently" because the user is left unaware of what Emacs did
in this case.  We don't even show a warning or any other informative
message.

> In this case, Paul's commit changes the current_lock_owner() function
> such that it returns zero upon ENOTDIR. The caller must interpret the
> zero return as meaning "at the time current_lock_owner() was called,
> nobody owned the lock file...or the lock file was obsolete."
> 
> ENOTDIR has a specific meaning that we can rely on. Both ENOENT and
> ENOTDIR imply that the file was definitely not on disk at the time of
> the call. Because of this, current_lock_owner() can safely conclude that
> nobody owned the lock.

"Definitely"? "safely"?  How do you arrive at that conclusion?

The Posix spec of 'unlink' says:

  [ENOTDIR]
      A component of the path prefix names an existing file that is
      neither a directory nor a symbolic link to a directory, or the
      path argument contains at least one non- <slash> character and
      ends with one or more trailing <slash> characters and the last
      pathname component names an existing file that is neither a
      directory nor a symbolic link to a directory.

It doesn't even say which component of the file name is not a
directory, nor does it distinguish between the two different use cases
that could cause ENOTDIR.  How can current_lock_owner decide, on these
shaky grounds alone, that nobody owned the lock, let alone do that
'safely"?

My point is that the values of errno provide too little information
for a safe decision here, one that couldn't possibly be wrong.  It
could be the scenario that triggered this bug report, but it could be
something entirely different.  We just don't know enough, and any
assumptions in this situation can definitely err.

Which is why I still think that we need to bring the user into the
loop.  Users will know what could or did happen, and even if they
don't, they are in charge of resolving the situation.  These problems
are rare enough to not make prompting the user for the appropriate
action an annoyance, so there's no good reason not to do so.  Doing so
will, as a nice bonus, also solve similar problems for any other value
of errno, once and for all.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 12 Feb 2021 07:15:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 12 02:15:50 2021
Received: from localhost ([127.0.0.1]:59821 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lASg9-0004Kd-S2
	for submit <at> debbugs.gnu.org; Fri, 12 Feb 2021 02:15:50 -0500
Received: from eggs.gnu.org ([209.51.188.92]:40820)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lASg7-0004KQ-5G
 for 46397 <at> debbugs.gnu.org; Fri, 12 Feb 2021 02:15:47 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:60834)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lASfz-0007vH-Dx; Fri, 12 Feb 2021 02:15:41 -0500
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1657
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1lASfs-0002DA-4h; Fri, 12 Feb 2021 02:15:36 -0500
Date: Fri, 12 Feb 2021 09:15:38 +0200
Message-Id: <83tuqhg3j9.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-Reply-To: <f7079852-58f6-1eb4-9d68-35251c1938ff@HIDDEN> (message from
 Paul Eggert on Thu, 11 Feb 2021 18:20:44 -0800)
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
 <m2blcskbyq.fsf@HIDDEN> <83a6scj745.fsf@HIDDEN>
 <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN>
 <m2blcqckv7.fsf@HIDDEN>
 <f7079852-58f6-1eb4-9d68-35251c1938ff@HIDDEN>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 46397
Cc: gmatta@HIDDEN, 46397 <at> debbugs.gnu.org, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> Cc: 46397 <at> debbugs.gnu.org, craven@HIDDEN
> From: Paul Eggert <eggert@HIDDEN>
> Date: Thu, 11 Feb 2021 18:20:44 -0800
> 
> On 2/11/21 2:14 PM, Matt Armstrong wrote:
> 
> > The issue isn't confined to exiting Emacs. It appears that once in a
> > "tricky situation where the file can't be unlocked for whatever reason"
> > Emacs will refuse to kill the buffer because unlock_file() signals an
> > error.
> 
> kill-buffer already asks the user something like "Buffer XXX modified; 
> kill anyway? (yes or no)" when killing a buffer that's been changed 
> without being saved. Perhaps it should also ask "File XXX cannot be 
> unlocked; kill buffer anyway? (yes or no)" if the file can't be unlocked.
> 
> > Note that shut_down_emacs() calls Fdo_auto_save() just before
> > unlock_all_files() and that call succeeds. Fdo_auto_save() also calls
> > report_file_errno, throwing an errno 13 (Permission denied), but that
> > recovers and continues.
> 
> Presumably shut_down_emacs should recover and continue if 
> unlock_all_files fails when it directly calls unlock_all_files.

That all is true, but I think we should provide for recovery in a way
that will work with _any_ command that calls unlock_file or
unlock_all_files.  Not just these two instances.  See my other message
about this.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 12 Feb 2021 02:20:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 11 21:20:55 2021
Received: from localhost ([127.0.0.1]:59633 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lAO4l-0005Wx-3X
	for submit <at> debbugs.gnu.org; Thu, 11 Feb 2021 21:20:55 -0500
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:34760)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1lAO4h-0005Wh-1r
 for 46397 <at> debbugs.gnu.org; Thu, 11 Feb 2021 21:20:54 -0500
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9454A1600F7;
 Thu, 11 Feb 2021 18:20:45 -0800 (PST)
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 weyCHQy9vDmR; Thu, 11 Feb 2021 18:20:44 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id E22C01600FC;
 Thu, 11 Feb 2021 18:20:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
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 VwhaFeZZHgnE; Thu, 11 Feb 2021 18:20:44 -0800 (PST)
Received: from [192.168.1.9] (cpe-23-243-218-95.socal.res.rr.com
 [23.243.218.95])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id B2ECD1600F7;
 Thu, 11 Feb 2021 18:20:44 -0800 (PST)
To: Matt Armstrong <gmatta@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
 <m2blcskbyq.fsf@HIDDEN> <83a6scj745.fsf@HIDDEN>
 <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN>
 <m2blcqckv7.fsf@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
Message-ID: <f7079852-58f6-1eb4-9d68-35251c1938ff@HIDDEN>
Date: Thu, 11 Feb 2021 18:20:44 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <m2blcqckv7.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.8 (/)
X-Debbugs-Envelope-To: 46397
Cc: 46397 <at> debbugs.gnu.org, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.8 (-)

On 2/11/21 2:14 PM, Matt Armstrong wrote:

> The issue isn't confined to exiting Emacs. It appears that once in a
> "tricky situation where the file can't be unlocked for whatever reason"
> Emacs will refuse to kill the buffer because unlock_file() signals an
> error.

kill-buffer already asks the user something like "Buffer XXX modified;=20
kill anyway? (yes or no)" when killing a buffer that's been changed=20
without being saved. Perhaps it should also ask "File XXX cannot be=20
unlocked; kill buffer anyway? (yes or no)" if the file can't be unlocked.

> Note that shut_down_emacs() calls Fdo_auto_save() just before
> unlock_all_files() and that call succeeds. Fdo_auto_save() also calls
> report_file_errno, throwing an errno 13 (Permission denied), but that
> recovers and continues.

Presumably shut_down_emacs should recover and continue if=20
unlock_all_files fails when it directly calls unlock_all_files.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 11 Feb 2021 22:15:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 11 17:15:07 2021
Received: from localhost ([127.0.0.1]:59498 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lAKEt-0008A9-Er
	for submit <at> debbugs.gnu.org; Thu, 11 Feb 2021 17:15:07 -0500
Received: from relay1-d.mail.gandi.net ([217.70.183.193]:57297)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gmatta@HIDDEN>) id 1lAKEq-00089K-7d
 for 46397 <at> debbugs.gnu.org; Thu, 11 Feb 2021 17:15:05 -0500
X-Originating-IP: 24.113.169.116
Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com
 [24.113.169.116]) (Authenticated sender: matt@HIDDEN)
 by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id 115D1240002;
 Thu, 11 Feb 2021 22:14:55 +0000 (UTC)
From: Matt Armstrong <gmatta@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
In-Reply-To: <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN>
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
 <m2blcskbyq.fsf@HIDDEN> <83a6scj745.fsf@HIDDEN>
 <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN>
Date: Thu, 11 Feb 2021 14:14:52 -0800
Message-ID: <m2blcqckv7.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: Paul Eggert writes: > The second bug is that once you're in
 a tricky situation where the file > can't be unlocked for whatever reason
 and you attempt to exit Emacs, > Emacs tries to auto-save the buffer, fails
 because of [...] 
 Content analysis details:   (1.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (gmatta[at]gmail.com)
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [217.70.183.193 listed in list.dnswl.org]
 0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
 [217.70.183.193 listed in wl.mailspike.net]
 1.0 FORGED_GMAIL_RCVD      'From' gmail.com does not match 'Received'
 headers
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 1.0 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)
 0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
X-Debbugs-Envelope-To: 46397
Cc: 46397 <at> debbugs.gnu.org, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

Paul Eggert <eggert@HIDDEN> writes:

> The second bug is that once you're in a tricky situation where the file 
> can't be unlocked for whatever reason and you attempt to exit Emacs, 
> Emacs tries to auto-save the buffer, fails because of the lock problem, 
> and then gets into a weird state where you cannot do anything. This 
> problem can happen in other scenarios. For example:
>
> * Run Emacs and visit the file /tmp/a/b where /tmp/a does not exist. 
> Emacs will warn "Use M-x make-directory RET RET to create the directory 
> and its parents"; ignore the warning.
>
> * Type some characters so that /tmp/a/b's buffer is nonempty.
>
> * Create an inaccessible directory /tmp/a by running "mkdir -m 0 /tmp/a" 
> outside Emacs.
>
> * Type C-x C-c to exit Emacs. It will say "Save file /tmp/a/b?" Type 
> "n". It will then say "Modified buffers exist; exit anyway? (yes or 
> no)". Type "yes". Emacs will then hang, in a weird state where it is 
> trying to auto-save but hanging in the middle of that.
>
> I did not fix this latter problem, so it needs further investigation. 

Paul, I looked into this second issue a bit.

The issue isn't confined to exiting Emacs. It appears that once in a
"tricky situation where the file can't be unlocked for whatever reason"
Emacs will refuse to kill the buffer because unlock_file() signals an
error.

The problem is more severe when exiting Emacs because it occurs after
Emacs is in a half shut down state. The shutdown sequence does not take
kindly to the unhandled non-local exit.

I used this for a quick repro:

(cl-flet ((command-in-tmp (prog &rest args)
                   (with-temp-buffer
                     (cd-absolute "/tmp")
                     (apply #'call-process prog nil nil nil args))))
  (command-in-tmp "chmod" "u+rwx" "a")
  (command-in-tmp "rm" "-rf" "a")
  (find-file "/tmp/a/b")
  (insert "Hello, World!")
  (command-in-tmp "mkdir" "-m" "0" "a"))

At shutdown, the following call stack signals an error:

kill_emacs
 -> shut_down_emacs
  -> unlock_all_files
   -> unlock_file
    -> report_file_errno

In this case, the errno is "permission denied."

Note that shut_down_emacs() calls Fdo_auto_save() just before
unlock_all_files() and that call succeeds. Fdo_auto_save() also calls
report_file_errno, throwing an errno 13 (Permission denied), but that
recovers and continues.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 10 Feb 2021 22:39:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 10 17:39:52 2021
Received: from localhost ([127.0.0.1]:57356 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1l9y9H-00053A-OV
	for submit <at> debbugs.gnu.org; Wed, 10 Feb 2021 17:39:52 -0500
Received: from relay1-d.mail.gandi.net ([217.70.183.193]:36155)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <matt@HIDDEN>) id 1l9y9G-00052w-Bi
 for 46397 <at> debbugs.gnu.org; Wed, 10 Feb 2021 17:39:51 -0500
X-Originating-IP: 24.113.169.116
Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com
 [24.113.169.116]) (Authenticated sender: matt@HIDDEN)
 by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id BDC37240006;
 Wed, 10 Feb 2021 22:39:40 +0000 (UTC)
From: Matt Armstrong <matt@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
 <m2blcskbyq.fsf@HIDDEN> <83a6scj745.fsf@HIDDEN>
 <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN>
 <835z2ziu52.fsf@HIDDEN>
Date: Wed, 10 Feb 2021 14:39:36 -0800
In-Reply-To: <835z2ziu52.fsf@HIDDEN> (Eli Zaretskii's message of "Wed, 10 Feb
 2021 21:45:45 +0200")
Message-ID: <m25z2zfsyf.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (darwin)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 46397
Cc: gmatta@HIDDEN, 46397 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>,
 craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Eli Zaretskii <eliz@HIDDEN> writes:

>> Cc: craven@HIDDEN, 46397 <at> debbugs.gnu.org, Matt Armstrong <gmatta@HIDDEN>
>> From: Paul Eggert <eggert@HIDDEN>
>> Date: Wed, 10 Feb 2021 11:23:46 -0800
>> 
>> --- a/src/filelock.c
>> +++ b/src/filelock.c
>> @@ -532,7 +532,7 @@ current_lock_owner (lock_info_type *owner, char *lfname)
>>    /* If nonexistent lock file, all is well; otherwise, got strange error. */
>>    lfinfolen = read_lock_data (lfname, owner->user);
>>    if (lfinfolen < 0)
>> -    return errno == ENOENT ? 0 : errno;
>> +    return errno == ENOENT || errno == ENOTDIR ? 0 : errno;
>
> As I said, I don't think this is TRT.  Why should we silently ignore
> ENOTDIR? couldn't it mean some kind of malicious attack on the user's
> account, or some other trouble?
>
> We should not ignore these errors, we should ask the user what to do
> about them.  The user can tell us the error can be ignored, but we
> should not decide that without asking.

I think Paul's commit is a good one. I'll try to explain why.

The commit does not silently ignore ENOTDIR. Instead, it is explicitly
handles that particular error code it in a way that honors the lock file
API contract.

In this case, Paul's commit changes the current_lock_owner() function
such that it returns zero upon ENOTDIR. The caller must interpret the
zero return as meaning "at the time current_lock_owner() was called,
nobody owned the lock file...or the lock file was obsolete."

ENOTDIR has a specific meaning that we can rely on. Both ENOENT and
ENOTDIR imply that the file was definitely not on disk at the time of
the call. Because of this, current_lock_owner() can safely conclude that
nobody owned the lock.

Put another way, I think a clearer API spec for current_lock_owner()
would be:

/* Return -2 if the current process owns the lock file,

   or -1 if another process appears to own it (and set OWNER (if
       non-null) to info),

   or 0 if the lock file isn't there, or it is there but has no current
       owner,

   or an errno value if something is wrong with the locking mechanism. */

That spec is semantically equivalent to the current one, but makes it
more clear why ENOENT and ENOTDIR should cause the function to return
zero. Those errno values do not imply that "something is wrong with the
locking mechanism."

Up a level of abstraction, the callers of the lock file API are still
presented with coherent semantics, even if current_lock_owner() returns
"lock file not owned" when the directory is missing. If the higher level
code wants to acquire the lock, it will attempt that and get an error at
that time. If the higher level code wants to abandon a buffer, it can
just do that knowing that this process definitely doesn't own that lock.
In neither case the user need not be interrogated, and if they do, it
will be done at a time that makes much more sense to them -- when
actually trying to acquire the lock.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 10 Feb 2021 19:45:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 10 14:45:55 2021
Received: from localhost ([127.0.0.1]:57274 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1l9vQw-0005xk-KJ
	for submit <at> debbugs.gnu.org; Wed, 10 Feb 2021 14:45:54 -0500
Received: from eggs.gnu.org ([209.51.188.92]:38268)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1l9vQt-0005rC-SA
 for 46397 <at> debbugs.gnu.org; Wed, 10 Feb 2021 14:45:53 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:54628)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1l9vQn-0003qH-Nq; Wed, 10 Feb 2021 14:45:45 -0500
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1537
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1l9vQm-0008Qs-Lg; Wed, 10 Feb 2021 14:45:45 -0500
Date: Wed, 10 Feb 2021 21:45:45 +0200
Message-Id: <835z2ziu52.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Paul Eggert <eggert@HIDDEN>
In-Reply-To: <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN> (message from
 Paul Eggert on Wed, 10 Feb 2021 11:23:46 -0800)
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
 <m2blcskbyq.fsf@HIDDEN> <83a6scj745.fsf@HIDDEN>
 <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 46397
Cc: gmatta@HIDDEN, 46397 <at> debbugs.gnu.org, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> Cc: craven@HIDDEN, 46397 <at> debbugs.gnu.org, Matt Armstrong <gmatta@HIDDEN>
> From: Paul Eggert <eggert@HIDDEN>
> Date: Wed, 10 Feb 2021 11:23:46 -0800
> 
> --- a/src/filelock.c
> +++ b/src/filelock.c
> @@ -532,7 +532,7 @@ current_lock_owner (lock_info_type *owner, char *lfname)
>    /* If nonexistent lock file, all is well; otherwise, got strange error. */
>    lfinfolen = read_lock_data (lfname, owner->user);
>    if (lfinfolen < 0)
> -    return errno == ENOENT ? 0 : errno;
> +    return errno == ENOENT || errno == ENOTDIR ? 0 : errno;

As I said, I don't think this is TRT.  Why should we silently ignore
ENOTDIR? couldn't it mean some kind of malicious attack on the user's
account, or some other trouble?

We should not ignore these errors, we should ask the user what to do
about them.  The user can tell us the error can be ignored, but we
should not decide that without asking.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 10 Feb 2021 19:23:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 10 14:23:56 2021
Received: from localhost ([127.0.0.1]:57250 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1l9v5f-0004ey-NE
	for submit <at> debbugs.gnu.org; Wed, 10 Feb 2021 14:23:56 -0500
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:33630)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1l9v5d-0004el-S9
 for 46397 <at> debbugs.gnu.org; Wed, 10 Feb 2021 14:23:54 -0500
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 65DFD16005D;
 Wed, 10 Feb 2021 11:23:48 -0800 (PST)
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 pj-rbGkhHWqL; Wed, 10 Feb 2021 11:23:47 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 37710160087;
 Wed, 10 Feb 2021 11:23:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
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 0d17747Onp4k; Wed, 10 Feb 2021 11:23:47 -0800 (PST)
Received: from [192.168.1.9] (cpe-23-243-218-95.socal.res.rr.com
 [23.243.218.95])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id C685816005D;
 Wed, 10 Feb 2021 11:23:46 -0800 (PST)
To: Eli Zaretskii <eliz@HIDDEN>
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
 <m2blcskbyq.fsf@HIDDEN> <83a6scj745.fsf@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
Message-ID: <39d0e035-27b6-e2bd-daa2-747dda2c1a35@HIDDEN>
Date: Wed, 10 Feb 2021 11:23:46 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <83a6scj745.fsf@HIDDEN>
Content-Type: multipart/mixed; boundary="------------A3DE93C10AF52A2D753617B8"
Content-Language: en-US
X-Spam-Score: -0.9 (/)
X-Debbugs-Envelope-To: 46397
Cc: Matt Armstrong <gmatta@HIDDEN>, 46397 <at> debbugs.gnu.org, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.9 (-)

This is a multi-part message in MIME format.
--------------A3DE93C10AF52A2D753617B8
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On 2/10/21 7:05 AM, Eli Zaretskii wrote:

> I think instead of ignoring some errors, we should allow the user to
> get out of these situations, after showing the error.  That is,
> instead of silently ignoring the error on some low level, we should
> propagate it to userlock.el and allow the user to decide whether
> he/she wants to ignore the error or do something about that.  These
> errors could mean something innocent, or they could mean something
> more serious, and we shouldn't second-guess which one is it.

I agree with this. However, I think there are two bugs here.

The first bug is that the low-level locking code is busted, in that it=20
thinks there's a lock file when ENOTDIR says there isn't. I installed=20
the first attached patch into master to fix this bug. This patch isn't=20
what Matt suggested - it's a bit earlier in the low-level C code where=20
the bug really occurred. (The area that Matt was looking at was later=20
on, when we have the lock and are removing it, and the ENOENT check=20
there is for the rare case where NFS is being used and its unlink=20
implementation gets confused and fails with ENOENT even though it was=20
actually successful and where any error other than ENOENT is serious.)

The second bug is that once you're in a tricky situation where the file=20
can't be unlocked for whatever reason and you attempt to exit Emacs,=20
Emacs tries to auto-save the buffer, fails because of the lock problem,=20
and then gets into a weird state where you cannot do anything. This=20
problem can happen in other scenarios. For example:

* Run Emacs and visit the file /tmp/a/b where /tmp/a does not exist.=20
Emacs will warn "Use M-x make-directory RET RET to create the directory=20
and its parents"; ignore the warning.

* Type some characters so that /tmp/a/b's buffer is nonempty.

* Create an inaccessible directory /tmp/a by running "mkdir -m 0 /tmp/a"=20
outside Emacs.

* Type C-x C-c to exit Emacs. It will say "Save file /tmp/a/b?" Type=20
"n". It will then say "Modified buffers exist; exit anyway? (yes or=20
no)". Type "yes". Emacs will then hang, in a weird state where it is=20
trying to auto-save but hanging in the middle of that.

I did not fix this latter problem, so it needs further investigation.=20
While looking into it, though, I did see some longstanding code in=20
files.el that could use a bit of sprucing up given the more-modern=20
primitives available now, and so installed the second attached patch=20
into master.

--------------A3DE93C10AF52A2D753617B8
Content-Type: text/x-patch; charset=UTF-8;
 name="0001-Fix-file-lock-issue-Bug-46397.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0001-Fix-file-lock-issue-Bug-46397.patch"

=46rom 4459dcc07865f6ae1f21f624fcb09cf8fdaecdb5 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@HIDDEN>
Date: Wed, 10 Feb 2021 10:50:44 -0800
Subject: [PATCH 1/2] Fix file lock issue (Bug#46397)

* src/filelock.c (current_lock_owner):
Also treat ENOTDIR as meaning the lock file does not exist.
---
 src/filelock.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/filelock.c b/src/filelock.c
index 35baa0c666..373fc00a42 100644
--- a/src/filelock.c
+++ b/src/filelock.c
@@ -532,7 +532,7 @@ current_lock_owner (lock_info_type *owner, char *lfna=
me)
   /* If nonexistent lock file, all is well; otherwise, got strange error=
=2E */
   lfinfolen =3D read_lock_data (lfname, owner->user);
   if (lfinfolen < 0)
-    return errno =3D=3D ENOENT ? 0 : errno;
+    return errno =3D=3D ENOENT || errno =3D=3D ENOTDIR ? 0 : errno;
   if (MAX_LFINFO < lfinfolen)
     return ENAMETOOLONG;
   owner->user[lfinfolen] =3D 0;
--=20
2.27.0


--------------A3DE93C10AF52A2D753617B8
Content-Type: text/x-patch; charset=UTF-8;
 name="0002-Simplify-and-speed-up-after-find-file.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0002-Simplify-and-speed-up-after-find-file.patch"

=46rom 4467073c50d2c7fbbb30530d1a0a25f8272ff56f Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@HIDDEN>
Date: Wed, 10 Feb 2021 10:55:42 -0800
Subject: [PATCH 2/2] Simplify and speed up after-find-file

Use newer primitives like file-accessible-directory-p to simplify
and speed up longstanding code in after-find-file.
* lisp/files.el (after-find-file):
Prefer file-exists-p + file-symlink-p to file-attributes +
file-symlink-p + file-chase-links + file-exists-p.
Prefer file-accessible-directory-p to directory-file-name +
file-attributes.
Prefer file-directory-p to file-name-directory + file-exists-p.
---
 lisp/files.el | 17 +++++++----------
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/lisp/files.el b/lisp/files.el
index dada69c145..9ff8f31e37 100644
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -2530,13 +2530,11 @@ after-find-file
 	   (msg
 	    (cond
 	     ((not warn) nil)
-	     ((and error (file-attributes buffer-file-name))
+	     ((and error (file-exists-p buffer-file-name))
 	      (setq buffer-read-only t)
-	      (if (and (file-symlink-p buffer-file-name)
-		       (not (file-exists-p
-			     (file-chase-links buffer-file-name))))
-		  "Symbolic link that points to nonexistent file"
-		"File exists, but cannot be read"))
+	      "File exists, but cannot be read")
+	     ((and error (file-symlink-p buffer-file-name))
+	      "Symbolic link that points to nonexistent file")
 	     ((not buffer-read-only)
 	      (if (and warn
 		       ;; No need to warn if buffer is auto-saved
@@ -2553,13 +2551,12 @@ after-find-file
 	     ((not error)
 	      (setq not-serious t)
 	      "Note: file is write protected")
-	     ((file-attributes (directory-file-name default-directory))
+	     ((file-accessible-directory-p default-directory)
 	      "File not found and directory write-protected")
-	     ((file-exists-p (file-name-directory buffer-file-name))
-	      (setq buffer-read-only nil))
 	     (t
 	      (setq buffer-read-only nil)
-	      "Use M-x make-directory RET RET to create the directory and its p=
arents"))))
+	      (unless (file-directory-p default-directory)
+		"Use M-x make-directory RET RET to create the directory and its parent=
s")))))
       (when msg
 	(message "%s" msg)
 	(or not-serious (sit-for 1 t))))
--=20
2.27.0


--------------A3DE93C10AF52A2D753617B8--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 10 Feb 2021 15:05:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 10 10:05:42 2021
Received: from localhost ([127.0.0.1]:56851 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1l9r3m-0004dE-LT
	for submit <at> debbugs.gnu.org; Wed, 10 Feb 2021 10:05:42 -0500
Received: from eggs.gnu.org ([209.51.188.92]:58760)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1l9r3i-0004cz-VX
 for 46397 <at> debbugs.gnu.org; Wed, 10 Feb 2021 10:05:41 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:44892)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1l9r3c-0007IG-J4; Wed, 10 Feb 2021 10:05:32 -0500
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3269
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1l9r3b-0002K8-05; Wed, 10 Feb 2021 10:05:31 -0500
Date: Wed, 10 Feb 2021 17:05:30 +0200
Message-Id: <83a6scj745.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Matt Armstrong <gmatta@HIDDEN>
In-Reply-To: <m2blcskbyq.fsf@HIDDEN> (message from Matt Armstrong
 on Tue, 09 Feb 2021 16:23:09 -0800)
Subject: Re: bug#46397: 27.1;
 Cannot delete buffer pointing to a file in a path that includes a file
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
 <m2blcskbyq.fsf@HIDDEN>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 46397
Cc: 46397 <at> debbugs.gnu.org, eggert@HIDDEN, craven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> From: Matt Armstrong <gmatta@HIDDEN>
> Date: Tue, 09 Feb 2021 16:23:09 -0800
> Cc: 46397 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>
> 
> > The backtrace is unsurprising:
> >
> > Debugger entered--Lisp error: (file-error "Unlocking file" "Not a directory" "/private/tmp/tmp/test.txt")
> >   kill-buffer("test.txt")
> >   funcall-interactively(kill-buffer "test.txt")
> >   call-interactively(kill-buffer nil nil)
> >   command-execute(kill-buffer)
> 
> I found that this behavior was introduced by Paul Egger's commit
> 9dc306b1db0, discussed in Bug#37389.  I've cc'd Paul.
> 
> Paul's commit changed unlock_file() (from src/filelock.cc) to report
> errors from unlink(), excempting only ENOENT. This bug demonstrates a
> way to induce an ENOTDIR error. I've attached a patch that ignores
> ENOTDIR as well, which is the most conservative fix I can think of. It
> also seems in-line with Paul's original intent, since he was saying that
> both ENOENT and ENOTDIR are usually "tame."

I think instead of ignoring some errors, we should allow the user to
get out of these situations, after showing the error.  That is,
instead of silently ignoring the error on some low level, we should
propagate it to userlock.el and allow the user to decide whether
he/she wants to ignore the error or do something about that.  These
errors could mean something innocent, or they could mean something
more serious, and we shouldn't second-guess which one is it.

Letting the user decide will also seamlessly solve any other type of
error that could happen when we try to delete the lock file.

So how about coming up with a patch that shows the error message to
the users and asks them whether or not to ignore that and kill the
buffer?

Thanks.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 10 Feb 2021 01:47:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 09 20:47:29 2021
Received: from localhost ([127.0.0.1]:55189 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1l9ebF-0003gp-Qg
	for submit <at> debbugs.gnu.org; Tue, 09 Feb 2021 20:47:29 -0500
Received: from mail-pg1-f181.google.com ([209.85.215.181]:40791)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gmatta@HIDDEN>) id 1l9dKr-0001gW-P1
 for 46397 <at> debbugs.gnu.org; Tue, 09 Feb 2021 19:26:27 -0500
Received: by mail-pg1-f181.google.com with SMTP id b21so68964pgk.7
 for <46397 <at> debbugs.gnu.org>; Tue, 09 Feb 2021 16:26:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:in-reply-to:references:user-agent:date
 :message-id:mime-version;
 bh=js0vBbkSTghLM2Q32AV1OkMLCy4TK+L2M2oaRHh4gNY=;
 b=ODS1oAp1Eh8BaS5LrHuy0LVcRnohupH/igRz+Shhqa3Jxlan+aXVI85KSgloFOuIK3
 k+qENTwxlCK4varj7D5FpwMkIOKxXIrVMCFjfuYlX3nrrxZGV6D2YBtaUl10+JgI2jLQ
 4PNAyHOTif1ziL1mzOMg5sJvS4F8/EFAGkNg05yf8dyAAJn4uIAKuM+nHQ8U+aYS8SFT
 3iqrNXq05NiQWDOgY/3L22ZwtBLPa6tlpucNVUjaIF8AgFtY/ujyQW9QQe62VoPcUDxF
 2KDsoeU/10q9peUdZzOwjbQq8w3pbZIJz60yyhXY/LfSDAgAaI/InP0wBB5LcdFqTbfj
 Fl+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:in-reply-to:references
 :user-agent:date:message-id:mime-version;
 bh=js0vBbkSTghLM2Q32AV1OkMLCy4TK+L2M2oaRHh4gNY=;
 b=VUykAurH24MrDHZy1tUMUVp1nIB6K5JBij1i40YXCJDGT1Jb4PELTk/F6nBz75UlvA
 U8BtEaH+TcpALm0UcyIBH9cyzX3ky+h8UMAw8j8oHoQUUWOAWTaaoiL7fvJiIPXhL9sJ
 GgNoXGac0MREtH/IykA59XPmkPQAZg/F0nYH9R24UV16a8EaYTe7s68j3DY6fS+MMAfQ
 RwpSar+emyTHC72qmvJs1Alzrve4waLSHwjyypN9FJZSCulefZm6+4ibxrAEvuZ6junY
 3LCKcnsx1NyobrRnHd+jxmavaBjfwugURk7hiIBBPBpgXMxbLrTzM9dO8obU0/+HINp8
 7Uew==
X-Gm-Message-State: AOAM532h4jGuvIRm/sVkh4kvitPTUEJfNCpU151ZBl78nYFC0qqkfLIi
 4nUgFxYcMiXkrVw7KSKfQRk=
X-Google-Smtp-Source: ABdhPJyYPTH/v1oBT7iKtCsxo3uAztgQ8Dt/UFzZndOFgV/2KILLZ9bdVExkNhegFJYY5yJgY0SpuA==
X-Received: by 2002:a62:4e10:0:b029:1c9:9015:dc5b with SMTP id
 c16-20020a624e100000b02901c99015dc5bmr376010pfb.30.1612916779929; 
 Tue, 09 Feb 2021 16:26:19 -0800 (PST)
Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com.
 [24.113.169.116])
 by smtp.gmail.com with ESMTPSA id e76sm83207pfh.102.2021.02.09.16.26.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 09 Feb 2021 16:26:19 -0800 (PST)
From: Matt Armstrong <gmatta@HIDDEN>
X-Google-Original-From: Matt Armstrong <gmatta@HIDDEN>
To: "Peter" <craven@HIDDEN>
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
In-Reply-To: <m2k0rgkdlr.fsf@HIDDEN> (Matt Armstrong's message of
 "Tue, 09 Feb 2021 15:47:44 -0800")
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (darwin)
Date: Tue, 09 Feb 2021 16:26:18 -0800
Message-ID: <m2a6sckbth.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 46397
X-Mailman-Approved-At: Tue, 09 Feb 2021 20:47:23 -0500
Cc: 46397 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--=-=-=
Content-Type: text/plain

Matt Armstrong <matt@HIDDEN> writes:

> "Peter" <craven@HIDDEN> writes:
>
>> The following steps reproduce this:
>> - Make sure /tmp/tmp does not exist
>> - Open a buffer /tmp/tmp/foo.txt
>> - Make some changes to the buffer.
>> - Do *not* save the buffer or create the directory /tmp/tmp/
>> - Create /tmp/tmp as a *file* (not a directory)
>> - Try to kill the buffer.
>>
>> You will see the following error message:
>>
>> Unlocking file: Not a directory, /tmp/tmp/foo.txt
>>
>> I just want to kill the buffer, I don't want to save it.

[...]

> The backtrace is unsurprising:
>
> Debugger entered--Lisp error: (file-error "Unlocking file" "Not a directory" "/private/tmp/tmp/test.txt")
>   kill-buffer("test.txt")
>   funcall-interactively(kill-buffer "test.txt")
>   call-interactively(kill-buffer nil nil)
>   command-execute(kill-buffer)

I found that this behavior was introduced by Paul Egger's commit
9dc306b1db0, discussed in Bug#37389.  I've cc'd Paul.

Paul's commit changed unlock_file() (from src/filelock.cc) to report
errors from unlink(), excempting only ENOENT. This bug demonstrates a
way to induce an ENOTDIR error. I've attached a patch that ignores
ENOTDIR as well, which is the most conservative fix I can think of. It
also seems in-line with Paul's original intent, since he was saying that
both ENOENT and ENOTDIR are usually "tame."


--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
 filename=0001-Ignore-ENOTDIR-errors-from-unlink.patch
Content-Description: Ignore ENOTDIR

From fc0b7f2595bd8680952f062d2dd5261f94394e1c Mon Sep 17 00:00:00 2001
From: Matt Armstrong <matt@HIDDEN>
Date: Tue, 9 Feb 2021 16:14:28 -0800
Subject: [PATCH] Ignore ENOTDIR errors from unlink().

* src/filelock.c (unlock_file): Ignore ENOTDIR errors from unlink().
---
 src/filelock.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/filelock.c b/src/filelock.c
index 35baa0c666..af5683f365 100644
--- a/src/filelock.c
+++ b/src/filelock.c
@@ -731,7 +731,8 @@ unlock_file (Lisp_Object fn)
   MAKE_LOCK_NAME (lfname, fn);
 
   int err = current_lock_owner (0, lfname);
-  if (err == -2 && unlink (lfname) != 0 && errno != ENOENT)
+  if (err == -2 && unlink (lfname) != 0
+      && (errno != ENOENT && errno != ENOTDIR))
     err = errno;
   if (0 < err)
     report_file_errno ("Unlocking file", filename, err);
-- 
2.30.0


--=-=-=--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 10 Feb 2021 01:47:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 09 20:47:25 2021
Received: from localhost ([127.0.0.1]:55187 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1l9ebF-0003gi-8v
	for submit <at> debbugs.gnu.org; Tue, 09 Feb 2021 20:47:25 -0500
Received: from mail-pj1-f47.google.com ([209.85.216.47]:53762)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gmatta@HIDDEN>) id 1l9dHo-0001an-R9
 for 46397 <at> debbugs.gnu.org; Tue, 09 Feb 2021 19:23:18 -0500
Received: by mail-pj1-f47.google.com with SMTP id nm1so126645pjb.3
 for <46397 <at> debbugs.gnu.org>; Tue, 09 Feb 2021 16:23:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version;
 bh=js0vBbkSTghLM2Q32AV1OkMLCy4TK+L2M2oaRHh4gNY=;
 b=Z/YR2C4n0AyKxkkvTzHjn1fYyvxTuOyX7Sxvd8tYqVzAdJiygwdETb3tRxIP6MQZ5X
 UZDgcwNjN+X9YCygnXiatHhBJOf4dUvs6huh1I+y6xRFNVw7Y2BlpsmdDAoX38wYCive
 m2jAQhNVmDfBIMlNMrF/cjrN5uadXE9G4tO/f3AcVt72ucwXWXSxFcHxHBZIpWf/WG0w
 BDbucGHzOACkRYyyNL7xcusybJV+I1PpdAOXuPMJylXhO0UjJF41hHSSHELSq4wXRKpm
 +iv8L1wwLt8vufdMqslFpIzOhBT6D/6mFYmsW3SIFjTVLFtx7fM8OmvaPAhROnqh8v+K
 Q/gQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version;
 bh=js0vBbkSTghLM2Q32AV1OkMLCy4TK+L2M2oaRHh4gNY=;
 b=LQ2NZtmZsycGU4iS0em4R2G/9xwu3j+hweaeI/S//5W/9bBq7pPKcMr0Jy/MhmpJ+1
 Q2vrsY38ZBMMPBeqdlOtPTeREQU9kDhpuNQAbK7B5oPPGbQMiUtZvAV37E5pXyrsoJEE
 NpOUoTOEA8H6ORbjsp3/qBQYmprIvF93ey96XcE3H0FvRwu7IE6Tj+ArkNeMbrGq5hdA
 MYKP+4OYYRQkVYg9cMQIt+DnKnvuVG1OHIKyfBdcrseB/UuVX6cMtRw0VliBOJN27LBZ
 XGsj5gYQp5WDHV+QiaCQMAipivHqQxHKviVvwSKhVmsocDkJTqJ4U2Mih1NXB4swpBuF
 SQVA==
X-Gm-Message-State: AOAM531xBKVUUENxA0pnpqyQb+7RVIs3SN3uISdtL4cExW2YgkGko8dD
 MzCESKUFv7JUUokAt49876Y=
X-Google-Smtp-Source: ABdhPJzp0oHNTw7/qFzgdws5ZC3i7jPC1yiUCo0PIpFklixc3JeTDrmojj8xtenxMqGoL8zIrT8NLg==
X-Received: by 2002:a17:902:8a95:b029:e3:484:a4a with SMTP id
 p21-20020a1709028a95b02900e304840a4amr61994plo.13.1612916590656; 
 Tue, 09 Feb 2021 16:23:10 -0800 (PST)
Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com.
 [24.113.169.116])
 by smtp.gmail.com with ESMTPSA id v9sm179313pju.33.2021.02.09.16.23.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 09 Feb 2021 16:23:10 -0800 (PST)
From: Matt Armstrong <gmatta@HIDDEN>
X-Google-Original-From: Matt Armstrong <gmatta@HIDDEN>
To: "Peter" <craven@HIDDEN>
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
References: <87h7mllgin.fsf@HIDDEN> <m2k0rgkdlr.fsf@HIDDEN>
Date: Tue, 09 Feb 2021 16:23:09 -0800
In-Reply-To: <m2k0rgkdlr.fsf@HIDDEN> (Matt Armstrong's message of
 "Tue, 09 Feb 2021 15:47:44 -0800")
Message-ID: <m2blcskbyq.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (darwin)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 46397
X-Mailman-Approved-At: Tue, 09 Feb 2021 20:47:23 -0500
Cc: 46397 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--=-=-=
Content-Type: text/plain

Matt Armstrong <matt@HIDDEN> writes:

> "Peter" <craven@HIDDEN> writes:
>
>> The following steps reproduce this:
>> - Make sure /tmp/tmp does not exist
>> - Open a buffer /tmp/tmp/foo.txt
>> - Make some changes to the buffer.
>> - Do *not* save the buffer or create the directory /tmp/tmp/
>> - Create /tmp/tmp as a *file* (not a directory)
>> - Try to kill the buffer.
>>
>> You will see the following error message:
>>
>> Unlocking file: Not a directory, /tmp/tmp/foo.txt
>>
>> I just want to kill the buffer, I don't want to save it.

[...]

> The backtrace is unsurprising:
>
> Debugger entered--Lisp error: (file-error "Unlocking file" "Not a directory" "/private/tmp/tmp/test.txt")
>   kill-buffer("test.txt")
>   funcall-interactively(kill-buffer "test.txt")
>   call-interactively(kill-buffer nil nil)
>   command-execute(kill-buffer)

I found that this behavior was introduced by Paul Egger's commit
9dc306b1db0, discussed in Bug#37389.  I've cc'd Paul.

Paul's commit changed unlock_file() (from src/filelock.cc) to report
errors from unlink(), excempting only ENOENT. This bug demonstrates a
way to induce an ENOTDIR error. I've attached a patch that ignores
ENOTDIR as well, which is the most conservative fix I can think of. It
also seems in-line with Paul's original intent, since he was saying that
both ENOENT and ENOTDIR are usually "tame."


--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
 filename=0001-Ignore-ENOTDIR-errors-from-unlink.patch
Content-Description: Ignore ENOTDIR

From fc0b7f2595bd8680952f062d2dd5261f94394e1c Mon Sep 17 00:00:00 2001
From: Matt Armstrong <matt@HIDDEN>
Date: Tue, 9 Feb 2021 16:14:28 -0800
Subject: [PATCH] Ignore ENOTDIR errors from unlink().

* src/filelock.c (unlock_file): Ignore ENOTDIR errors from unlink().
---
 src/filelock.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/filelock.c b/src/filelock.c
index 35baa0c666..af5683f365 100644
--- a/src/filelock.c
+++ b/src/filelock.c
@@ -731,7 +731,8 @@ unlock_file (Lisp_Object fn)
   MAKE_LOCK_NAME (lfname, fn);
 
   int err = current_lock_owner (0, lfname);
-  if (err == -2 && unlink (lfname) != 0 && errno != ENOENT)
+  if (err == -2 && unlink (lfname) != 0
+      && (errno != ENOENT && errno != ENOTDIR))
     err = errno;
   if (0 < err)
     report_file_errno ("Unlocking file", filename, err);
-- 
2.30.0


--=-=-=--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at 46397 <at> debbugs.gnu.org:


Received: (at 46397) by debbugs.gnu.org; 9 Feb 2021 23:47:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 09 18:47:55 2021
Received: from localhost ([127.0.0.1]:55068 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1l9cjb-0000lK-FQ
	for submit <at> debbugs.gnu.org; Tue, 09 Feb 2021 18:47:55 -0500
Received: from mail-pg1-f179.google.com ([209.85.215.179]:32800)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gmatta@HIDDEN>) id 1l9cjY-0000l6-OH
 for 46397 <at> debbugs.gnu.org; Tue, 09 Feb 2021 18:47:54 -0500
Received: by mail-pg1-f179.google.com with SMTP id e7so34220pge.0
 for <46397 <at> debbugs.gnu.org>; Tue, 09 Feb 2021 15:47:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version;
 bh=Z7Krv5J/GhP1Rp/2pxfIhUuVI7W7JcTNzeD80OGQaJo=;
 b=lKowd+0ZU6EJOTJpBJrJ9CEDpV8n6XHQeGZ3wRj7gj887YobPOq+MiZFYkO1uAIrqI
 uPRBh775vWgO2OB5Bqm61NwSY3DalDT1SUJq2UBR5AokOxRLgDJC0pZjoXiJWPmAYxs/
 uzQGYwH+H0SA8cKrz4o9AZXDvTRh9pWCMWPSdsRfZg/vGqpTOcJ1fjOD7vQzmp2L6ioL
 rJuQTy9n6Ftgea3wPd/OmkcH1nXJD3Q3jwal7f7CUuCX5PRG130WqXFs2n08KrLDnVKE
 C9A/qpVz7W/WDnu8U3MlScck1Vi/yautnl727jT4FUvuqEO2WRX4zckWt6NBQvgG0uqt
 uUQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:from:to:cc:subject:references:date
 :in-reply-to:message-id:user-agent:mime-version;
 bh=Z7Krv5J/GhP1Rp/2pxfIhUuVI7W7JcTNzeD80OGQaJo=;
 b=NAks5dpfk7T2J2I6SXFt3pmAWLM3JzXBCw5UhHLpfjRyZD8lx7yolCLu8ixREv/n9h
 h97y/Np58DThKWWN/r4iqBmsD7+UhC/Zgfl58y3GYqCB7mxRvTGFDUqijp6V26uiiLkL
 4nLxAQUHWDSzg+zO1s+ziaoejEyebJt0gECENnum0VZINBGlSjytIliDDRZsKyNQ2pkd
 upNo0K8CKISrLwjM+w/qqzGK3cfNgz+sqaMaCK0ccQObKQYclEqLGIf+k30IPUAAMITE
 p4AYNK5wYg5VzIGl3L3yB9DW8ukqDONDHkNvUrno6rrBOd86KecCQwi6Gda2/kCiWmCN
 UyRQ==
X-Gm-Message-State: AOAM530GrB1cMlsHDoLYGfuLhyv+KXypqNkpO6FCSLwB53ANKdSsGMvp
 jeOR1DEfFtiuXSW3wX5KukF3loq31I9noA==
X-Google-Smtp-Source: ABdhPJx+FWzidabI+T/eKqkGa4Wx24YB2VqOUZWu7/VIHZueVRFlh7T2hYUggAqZv9XWtcS/qfix5Q==
X-Received: by 2002:a05:6a00:8d0:b029:1b6:3581:4f41 with SMTP id
 s16-20020a056a0008d0b02901b635814f41mr351407pfu.56.1612914466235; 
 Tue, 09 Feb 2021 15:47:46 -0800 (PST)
Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com.
 [24.113.169.116])
 by smtp.gmail.com with ESMTPSA id v19sm145675pjg.50.2021.02.09.15.47.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 09 Feb 2021 15:47:45 -0800 (PST)
From: Matt Armstrong <matt@HIDDEN>
To: "Peter" <craven@HIDDEN>
Subject: Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a
 path that includes a file
References: <87h7mllgin.fsf@HIDDEN>
Date: Tue, 09 Feb 2021 15:47:44 -0800
In-Reply-To: <87h7mllgin.fsf@HIDDEN> (Peter's message of "Tue, 09 Feb 2021
 10:47:12 +0100")
Message-ID: <m2k0rgkdlr.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (darwin)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: 46397
Cc: 46397 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

"Peter" <craven@HIDDEN> writes:

> The following steps reproduce this:
> - Make sure /tmp/tmp does not exist
> - Open a buffer /tmp/tmp/foo.txt
> - Make some changes to the buffer.
> - Do *not* save the buffer or create the directory /tmp/tmp/
> - Create /tmp/tmp as a *file* (not a directory)
> - Try to kill the buffer.
>
> You will see the following error message:
>
> Unlocking file: Not a directory, /tmp/tmp/foo.txt
>
> I just want to kill the buffer, I don't want to save it.
>
> This is easily rectified by just deleting / moving away /tmp/tmp, but it
> seems like this could be resolved to just delete the buffer.

I confirmed this in 27.1 and the master branch. I also found it
difficult to exit Emacs once this state was reached. If you choose "no"
when saving modified buffers Emacs hits this error and is left in a
strange state (there are no displayed buffers or mode line, but Emacs is
still running).

The backtrace is unsurprising:

Debugger entered--Lisp error: (file-error "Unlocking file" "Not a directory" "/private/tmp/tmp/test.txt")
  kill-buffer("test.txt")
  funcall-interactively(kill-buffer "test.txt")
  call-interactively(kill-buffer nil nil)
  command-execute(kill-buffer)




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 9 Feb 2021 09:47:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 09 04:47:22 2021
Received: from localhost ([127.0.0.1]:52690 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1l9Pc9-0007bo-Qc
	for submit <at> debbugs.gnu.org; Tue, 09 Feb 2021 04:47:22 -0500
Received: from lists.gnu.org ([209.51.188.17]:49044)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <craven@HIDDEN>) id 1l9Pc7-0007bg-5G
 for submit <at> debbugs.gnu.org; Tue, 09 Feb 2021 04:47:20 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:47254)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <craven@HIDDEN>) id 1l9Pc6-00077h-S8
 for bug-gnu-emacs@HIDDEN; Tue, 09 Feb 2021 04:47:18 -0500
Received: from mout.gmx.net ([212.227.17.21]:42087)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <craven@HIDDEN>) id 1l9Pc4-0002UA-Tl
 for bug-gnu-emacs@HIDDEN; Tue, 09 Feb 2021 04:47:18 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net;
 s=badeba3b8450; t=1612864034;
 bh=gBf/gYoFj7OBriBy0jt159NWv2QImiN3KVuFv3sBTso=;
 h=X-UI-Sender-Class:From:To:Subject:Date;
 b=SDKb68+kVvDQ8DrsUIv5cUd8NoJBaY1EYjeAuH1v0O4TM5zJHdsedza+/v5kSkuAo
 hbwPlt0/9+mJ1t9XOSb+HbZ/uv0YVQ7ri614VADD7CsikbcvbbQpEE2ULVpBo+JBma
 MqTRGNhtKWrvLb/u7a7WzDDle+svFeT1PuQBMDr0=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from nexoid.at ([178.79.130.240]) by mail.gmx.net (mrgmx105
 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MzhjF-1m4w9Q43Wb-00viEa for
 <bug-gnu-emacs@HIDDEN>; Tue, 09 Feb 2021 10:47:14 +0100
From: "Peter" <craven@HIDDEN>
DKIM-Filter: OpenDKIM Filter v2.10.3 nexoid.at 39656BC81
To: bug-gnu-emacs@HIDDEN
Subject: 27.1; Cannot delete buffer pointing to a file in a path that
 includes a file
Date: Tue, 09 Feb 2021 10:47:12 +0100
Message-ID: <87h7mllgin.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Provags-ID: V03:K1:3I46pbVKRhgshvTqX3oTqaPyhHBomLmTlp080sE29xcRqjOS4DM
 csPJFbWE1u/rJflh9MUHgVugVihq+Dk4QxpHzFmQv2NuwMAeh6fCEGdbjnVLSoRJRrMVQT2
 rZJb9vg+9cp1B6JVRgE8EqD6WbFOylXjSIuWKKMU8i3xFHH13f1sUVkyahpuWJ4NIJ2m7Zo
 LR27wNBJOgT7IN+Kw/+MQ==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:Om0z1daVFfk=:3z5nx7MaWx4YWVWK5Cjrqv
 vROYHk6/8/sNzyZRwTwufu8pXhkbmhvPhoFr08nQgI1ju7ypoSpqljPnP0/MZOEx2qxkpvLpz
 GI/WdclupXEQu2TmxJQvCZ/dOmzimiOwf6MU7KBZMP9t59XUvTTrwa70dVVW4Q2o+wA/IuVC7
 F2htg7SpKgkYE8RH/R7GCIThX8KocqF8mTNF2x5Gi8kvMIZeVIwwTN/6qATqYFXlAFx2lK7/k
 mrx5cbEJRuhdxPY0nheGZfUQLnpcRyYIIgQwv2lg7R43mzW+1Jcj6YOJSWeSg2KWEmFiTr7wF
 6Kv6x5HgJhhqEvT/q2FwJJtZ2FyZPtUsmooYH1YuPIGjckC/nk5W8Eh9MpN/BMercGluLlCcM
 Fa7ria55o6fPhbkbZv8wWmutzhwkQGl7UAb+XnCA7HQtmwk8UHD0gKamPbSkH9CoAmmCx2RtU
 7Hz7YhhSvCk1yTo4RR9+E/IHj79MfadEMCAa/3UwSLULATfPqUVD2VJzlzAzfw5Eyz8lOigCj
 hexmWgiYLSLMgFGzxMI1UADPfjY/ulgyPDTFkaCx3V/j5GbRKxr65ggC48fDq999qKQUgYxSK
 Ij9RMSWVKl95Y3O2p2Cv1zRpWGXvZ3thE/JOJBQ9YRzYcjmpFinYFo6keuQYjiULfbuj7RIhj
 qreV0t4T4ahTFII00g86+C/3U0dLwjZOP3RjN9Eqns22rZ6gJkzU0De62sOE7yPhmrpH4P3PQ
 61aiublewiu23tJNZ17fJyBwHwvA0ZLolxBqQVQZhdjRiturn6ntUco+/mHn4p7vCTgLH/Qek
 PavypuWH1N/l9ldKdAF9KKYQISAyLLJU3//pgI+6T6UArUwkN1UBIAlvNYJ71V4ykkxifNp+w
 LRU7LfsVx5pgbdr7x51Q==
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=212.227.17.21; envelope-from=craven@HIDDEN;
 helo=mout.gmx.net
X-Spam_score_int: -27
X-Spam_score: -2.8
X-Spam_bar: --
X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.4 (--)

The following steps reproduce this:
- Make sure /tmp/tmp does not exist
- Open a buffer /tmp/tmp/foo.txt
- Make some changes to the buffer.
- Do *not* save the buffer or create the directory /tmp/tmp/
- Create /tmp/tmp as a *file* (not a directory)
- Try to kill the buffer.

You will see the following error message:

Unlocking file: Not a directory, /tmp/tmp/foo.txt

I just want to kill the buffer, I don't want to save it.

This is easily rectified by just deleting / moving away /tmp/tmp, but it
seems like this could be resolved to just delete the buffer.

Greetings, Peter



In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22, cai=
ro version 1.17.3)
 of 2020-08-28 built on juergen
Windowing system distributor 'The X.Org Foundation', version 11.0.12010000
System Description: Arch Linux

Recent messages:
<right-margin> <triple-down-mouse-4> is undefined
<right-margin> <triple-mouse-4> is undefined
<right-margin> <triple-down-mouse-4> is undefined
<right-margin> <triple-mouse-4> is undefined
Mark saved where search started
Mark set
Mark saved where search started [2 times]
mouse-2: copy to input; mouse-3: menu [3 times]
Mark set [4 times]
Mark saved where search started [3 times]

Configured using:
 'configure --prefix=3D/usr --sysconfdir=3D/etc --libexecdir=3D/usr/lib
 --localstatedir=3D/var --with-x-toolkit=3Dgtk3 --with-xft --with-wide-int
 --with-modules --with-cairo --with-harfbuzz 'CFLAGS=3D-march=3Dx86-64
 -mtune=3Dgeneric -O2 -pipe -fno-plt' CPPFLAGS=3D-D_FORTIFY_SOURCE=3D2
 LDFLAGS=3D-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON
PDUMPER LCMS2 GMP

Important settings:
  value of $LC_COLLATE: C
  value of $LC_MESSAGES:
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix




Acknowledgement sent to "Peter" <craven@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#46397; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Wed, 24 Feb 2021 19:00:01 UTC

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