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: Wed, 10 Feb 2021 21:45:45 +0200 Message-ID: <835z2ziu52.fsf@gnu.org> References: <87h7mllgin.fsf@nexoid.at> <83a6scj745.fsf@gnu.org> <39d0e035-27b6-e2bd-daa2-747dda2c1a35@cs.ucla.edu> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38605"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gmatta@gmail.com, 46397@debbugs.gnu.org, craven@gmx.net To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 10 20:46:26 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 1l9vRR-0009sj-Cf for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 10 Feb 2021 20:46:25 +0100 Original-Received: from localhost ([::1]:33898 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l9vRQ-0008UO-D7 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 10 Feb 2021 14:46:24 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56160) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l9vR6-0008Tz-Fb for bug-gnu-emacs@gnu.org; Wed, 10 Feb 2021 14:46:06 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45728) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l9vR4-0003uc-5u for bug-gnu-emacs@gnu.org; Wed, 10 Feb 2021 14:46:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l9vR4-00065b-2r for bug-gnu-emacs@gnu.org; Wed, 10 Feb 2021 14:46: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: Wed, 10 Feb 2021 19:46: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.161298635522949 (code B ref 46397); Wed, 10 Feb 2021 19:46:02 +0000 Original-Received: (at 46397) by debbugs.gnu.org; 10 Feb 2021 19:45:55 +0000 Original-Received: from localhost ([127.0.0.1]:57274 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l9vQw-0005xk-KJ for submit@debbugs.gnu.org; Wed, 10 Feb 2021 14:45:54 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38268) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l9vQt-0005rC-SA for 46397@debbugs.gnu.org; Wed, 10 Feb 2021 14:45:53 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:54628) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l9vQn-0003qH-Nq; Wed, 10 Feb 2021 14:45:45 -0500 Original-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 ) id 1l9vQm-0008Qs-Lg; Wed, 10 Feb 2021 14:45:45 -0500 In-Reply-To: <39d0e035-27b6-e2bd-daa2-747dda2c1a35@cs.ucla.edu> (message from Paul Eggert on Wed, 10 Feb 2021 11:23:46 -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:199796 Archived-At: > Cc: craven@gmx.net, 46397@debbugs.gnu.org, Matt Armstrong > From: Paul Eggert > 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.