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: Tue, 09 Feb 2021 16:26:18 -0800 Message-ID: References: <87h7mllgin.fsf@nexoid.at> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6488"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (darwin) Cc: 46397@debbugs.gnu.org, Paul Eggert To: "Peter" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 10 02:48:18 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 1l9ec5-0001aL-Nv for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 10 Feb 2021 02:48:17 +0100 Original-Received: from localhost ([::1]:53816 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l9ec4-0007hH-P8 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 09 Feb 2021 20:48:16 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49428) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l9ebs-0007gr-Fl for bug-gnu-emacs@gnu.org; Tue, 09 Feb 2021 20:48:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43645) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l9ebr-0003dx-Bd for bug-gnu-emacs@gnu.org; Tue, 09 Feb 2021 20:48:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l9ebr-0003iE-AI for bug-gnu-emacs@gnu.org; Tue, 09 Feb 2021 20:48:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Matt Armstrong Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Feb 2021 01:48:03 +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.161292164914202 (code B ref 46397); Wed, 10 Feb 2021 01:48:03 +0000 Original-Received: (at 46397) by debbugs.gnu.org; 10 Feb 2021 01:47:29 +0000 Original-Received: from localhost ([127.0.0.1]:55189 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l9ebF-0003gp-Qg for submit@debbugs.gnu.org; Tue, 09 Feb 2021 20:47:29 -0500 Original-Received: from mail-pg1-f181.google.com ([209.85.215.181]:40791) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l9dKr-0001gW-P1 for 46397@debbugs.gnu.org; Tue, 09 Feb 2021 19:26:27 -0500 Original-Received: by mail-pg1-f181.google.com with SMTP id b21so68964pgk.7 for <46397@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) Original-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) X-Google-Original-From: Matt Armstrong In-Reply-To: (Matt Armstrong's message of "Tue, 09 Feb 2021 15:47:44 -0800") X-Mailman-Approved-At: Tue, 09 Feb 2021 20:47:23 -0500 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:199749 Archived-At: --=-=-= Content-Type: text/plain Matt Armstrong writes: > "Peter" 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 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 --=-=-=--