From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii 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 13:33:01 +0200 Message-ID: <83ft21frma.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21568"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gmatta@gmail.com, 46397@debbugs.gnu.org, craven@gmx.net, matt@rfc20.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Feb 12 12:34:12 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 1lAWiB-0005VG-PT for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 12 Feb 2021 12:34:11 +0100 Original-Received: from localhost ([::1]:35494 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lAWiA-0003CE-SB for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 12 Feb 2021 06:34:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49936) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lAWi2-0003C5-Jg for bug-gnu-emacs@gnu.org; Fri, 12 Feb 2021 06:34:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48505) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lAWi2-0003sV-Bm for bug-gnu-emacs@gnu.org; Fri, 12 Feb 2021 06:34:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lAWi2-0004L8-7S for bug-gnu-emacs@gnu.org; Fri, 12 Feb 2021 06:34:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Feb 2021 11:34: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.161312958716603 (code B ref 46397); Fri, 12 Feb 2021 11:34:02 +0000 Original-Received: (at 46397) by debbugs.gnu.org; 12 Feb 2021 11:33:07 +0000 Original-Received: from localhost ([127.0.0.1]:60051 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lAWh8-0004Jj-JG for submit@debbugs.gnu.org; Fri, 12 Feb 2021 06:33:06 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60198) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lAWh5-0004JB-JW for 46397@debbugs.gnu.org; Fri, 12 Feb 2021 06:33:04 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41124) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lAWgx-0003Up-Ro; Fri, 12 Feb 2021 06:32:57 -0500 Original-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 ) id 1lAWgx-0008Ti-7D; Fri, 12 Feb 2021 06:32:55 -0500 In-Reply-To: <2ce4897b-56ac-9409-b5e8-c735528e48f1@cs.ucla.edu> (message from Paul Eggert on Fri, 12 Feb 2021 01:36:30 -0800) 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:199855 Archived-At: > 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.