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: Sun, 21 Feb 2021 17:42:38 -0800 Message-ID: References: <16051.1613951017@alto> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6493"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eggert@cs.ucla.edu, 46397@debbugs.gnu.org, craven@gmx.net, wohler@newt.com To: Mike Kupfer Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Feb 22 02:43:19 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 1lE0Fr-0001aW-IU for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 22 Feb 2021 02:43:19 +0100 Original-Received: from localhost ([::1]:54772 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lE0Fq-0004Pb-5Z for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 21 Feb 2021 20:43:18 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39242) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lE0Fb-0004PT-KR for bug-gnu-emacs@gnu.org; Sun, 21 Feb 2021 20:43:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43761) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lE0Fa-0008RR-9l for bug-gnu-emacs@gnu.org; Sun, 21 Feb 2021 20:43:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lE0Fa-0000Xm-5K for bug-gnu-emacs@gnu.org; Sun, 21 Feb 2021 20:43: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: Mon, 22 Feb 2021 01:43: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.16139581762077 (code B ref 46397); Mon, 22 Feb 2021 01:43:02 +0000 Original-Received: (at 46397) by debbugs.gnu.org; 22 Feb 2021 01:42:56 +0000 Original-Received: from localhost ([127.0.0.1]:55307 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lE0FU-0000XR-0O for submit@debbugs.gnu.org; Sun, 21 Feb 2021 20:42:56 -0500 Original-Received: from relay11.mail.gandi.net ([217.70.178.231]:60445) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lE0FQ-0000XB-MU for 46397@debbugs.gnu.org; Sun, 21 Feb 2021 20:42:55 -0500 Original-Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com [24.113.169.116]) (Authenticated sender: matt@rfc20.org) by relay11.mail.gandi.net (Postfix) with ESMTPSA id 49F5E100002; Mon, 22 Feb 2021 01:42:41 +0000 (UTC) In-Reply-To: <16051.1613951017@alto> 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:200535 Archived-At: Mike Kupfer writes: > (Adding Bill Wohler, who has a better grasp than I about why MH-E does > some things.) > > Matt Armstrong wrote: > >> Eli Zaretskii writes: >> >> > I think we should audit all the callers of unlock_buffer and >> > unlock_file, and see if signaling an error there is really the best >> > alternative. > [...] >> * lisp/mh-e/mh-show.el (mh-clean-msg-header, mh-unvisit-file): >> hard to say, very old code... >> * lisp/mh-e/mh-comp.el (mh-read-draft): ditto. > > I'm not sure I completely understanding the logic behind those calls to > unlock-buffer, but I'll take a stab at it. [...] Thanks for those analysis Mike. They make sense to me. > But to Eli's question, I think a signal is fine for MH-E if the > lockfile can't be removed for some reason. An uncaught signal could > leave the current buffer in an odd state, but the user can simply kill > the buffer and retry whatever operation she had attempted. Yes, and this bug is at least in part about the behavior of `kill-buffer' when faced with the same issue. That and `kill-emacs'. > Or if the buffer has something that is worth saving, the user can > attempt to save the buffer somewhere, perhaps a different filesystem > (e.g., if the original filesystem went read-only due to the OS > detecting a problem). I think the "buffer has something worth saving" case is not a concern. The calls to `unlock-buffer' all occur after the buffer contents have been saved, or otherwise marked as unmodified, or, in the case of `kill-buffer', after the user has chosen to not save a modified buffer. > I don't understand the proposal for unlock-buffer (or something under > it) to prompt the user. IIUC, the proposal is for a prompt like > >> /tmp/x/y lock is invalid; assume unlocked? (yes or no) > > I assume that if the user responds with "yes", unlock-buffer returns > and the caller is none the wiser. If the user responds with "no", > what happens? > > mike I think under the current idea, in the case of `kill-buffer', answering "no" from the prompt the buffer un-killed. I think the technical mechanism would be to either re-signal the underlying 'file-error or signal a new 'unlock-error that contains similar information.