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: Sat, 06 Mar 2021 21:57:02 -0800 Message-ID: <874khno6a9.fsf@mdeb> References: <83sg5r276b.fsf@gnu.org> <838s7j14xc.fsf@gnu.org> <837dmq95ee.fsf@gnu.org> <87y2f1meeu.fsf@mdeb> <83pn0cwrlx.fsf@gnu.org> <812e17db-1b3b-21cc-8f66-7d75e704c7cc@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24887"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46397@debbugs.gnu.org, craven@gmx.net To: Paul Eggert , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Mar 07 06:58:57 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 1lImRM-0006KM-6E for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 07 Mar 2021 06:58:56 +0100 Original-Received: from localhost ([::1]:42418 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lImRL-0007AY-8N for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 07 Mar 2021 00:58:55 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53682) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lImQU-00072r-Hk for bug-gnu-emacs@gnu.org; Sun, 07 Mar 2021 00:58:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55447) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lImQU-0000at-A7 for bug-gnu-emacs@gnu.org; Sun, 07 Mar 2021 00:58:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lImQU-0000Z1-7w for bug-gnu-emacs@gnu.org; Sun, 07 Mar 2021 00:58: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: Sun, 07 Mar 2021 05:58: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.16150966382105 (code B ref 46397); Sun, 07 Mar 2021 05:58:02 +0000 Original-Received: (at 46397) by debbugs.gnu.org; 7 Mar 2021 05:57:18 +0000 Original-Received: from localhost ([127.0.0.1]:38760 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lImPl-0000Xt-Rn for submit@debbugs.gnu.org; Sun, 07 Mar 2021 00:57:18 -0500 Original-Received: from relay7-d.mail.gandi.net ([217.70.183.200]:47179) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lImPj-0000Xf-NC for 46397@debbugs.gnu.org; Sun, 07 Mar 2021 00:57:16 -0500 X-Originating-IP: 24.113.169.116 Original-Received: from mdeb (24-113-169-116.wavecable.com [24.113.169.116]) (Authenticated sender: matt@rfc20.org) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id 2AA8B20008; Sun, 7 Mar 2021 05:57:06 +0000 (UTC) In-Reply-To: <812e17db-1b3b-21cc-8f66-7d75e704c7cc@cs.ucla.edu> 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:201717 Archived-At: Paul Eggert writes: > On 3/6/21 1:36 AM, Eli Zaretskii wrote: >> I'm asking what is the difference, from the file-locking POV, between >> an inaccessible directory and a directory that doesn't exist? > > In the former (EACCES) case, it's possible that the lockfile exists but > Emacs cannot remove it because the user currently lacks permissions to > an ancestor directory; this serious problem is worth reporting to the user. > > In the latter (ENOTDIR) case the lockfile cannot possibly exist, and > Emacs can treat ENOTDIR differently from EACCES for that reason. It > makes sense for Emacs to treat ENOTDIR like ENOENT, since in both cases > the lockfile cannot possibly exist and these are the only two error > numbers with that property. > > It might also make sense to treat ENOTDIR specially (neither like EACCES > nor like ENOENT) but that's a discussion we haven't had yet, as far as I > know. > > We've spent more time on this ENOENT/ENOTDIR issue than it's worth, so > feel free to revert my change and install whatever other change you > like. I'm sure there are lots of ways to fix the underlying problem. Okay, I'll work on that route, thanks Paul.