From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Matt Armstrong Newsgroups: gmane.emacs.bugs Subject: bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file Date: Fri, 12 Feb 2021 15:59:40 -0800 Message-ID: References: <87h7mllgin.fsf@nexoid.at> <83a6scj745.fsf@gnu.org> <39d0e035-27b6-e2bd-daa2-747dda2c1a35@cs.ucla.edu> <835z2ziu52.fsf@gnu.org> <83pn15g28y.fsf@gnu.org> <2ce4897b-56ac-9409-b5e8-c735528e48f1@cs.ucla.edu> <83ft21frma.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25431"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46397@debbugs.gnu.org, craven@gmx.net To: Eli Zaretskii , Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 13 01:00:38 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lAiMX-0006XQ-T4 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 13 Feb 2021 01:00:37 +0100 Original-Received: from localhost ([::1]:36036 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lAiMW-0001VD-UW for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 12 Feb 2021 19:00:36 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43776) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lAiLy-0001SX-Sr for bug-gnu-emacs@gnu.org; Fri, 12 Feb 2021 19:00:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49897) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lAiLy-0005fx-Km for bug-gnu-emacs@gnu.org; Fri, 12 Feb 2021 19:00:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lAiLy-0005PD-Ip for bug-gnu-emacs@gnu.org; Fri, 12 Feb 2021 19:00:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Matt Armstrong Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Feb 2021 00:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46397 X-GNU-PR-Package: emacs Original-Received: via spool by 46397-submit@debbugs.gnu.org id=B46397.161317439620742 (code B ref 46397); Sat, 13 Feb 2021 00:00:02 +0000 Original-Received: (at 46397) by debbugs.gnu.org; 12 Feb 2021 23:59:56 +0000 Original-Received: from localhost ([127.0.0.1]:33210 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lAiLr-0005OU-TZ for submit@debbugs.gnu.org; Fri, 12 Feb 2021 18:59:56 -0500 Original-Received: from relay8-d.mail.gandi.net ([217.70.183.201]:55403) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lAiLp-0005OE-0p for 46397@debbugs.gnu.org; Fri, 12 Feb 2021 18:59:55 -0500 X-Originating-IP: 24.113.169.116 Original-Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com [24.113.169.116]) (Authenticated sender: matt@rfc20.org) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 4697E1BF203; Fri, 12 Feb 2021 23:59:43 +0000 (UTC) In-Reply-To: <83ft21frma.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:199889 Archived-At: Eli Zaretskii writes: >> Cc: gmatta@gmail.com, 46397@debbugs.gnu.org, craven@gmx.net, >> Matt Armstrong >> From: Paul Eggert >> 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.