From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mike Kupfer 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 15:43:37 -0800 Message-ID: <16051.1613951017@alto> References: <87h7mllgin.fsf@nexoid.at> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40950"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eggert@cs.ucla.edu, 46397@debbugs.gnu.org, craven@gmx.net, wohler@newt.com To: Matt Armstrong Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Feb 22 00:44:31 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 1lDyOt-000AXv-DE for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 22 Feb 2021 00:44:31 +0100 Original-Received: from localhost ([::1]:54036 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lDyOs-0000Vh-7d for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 21 Feb 2021 18:44:30 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52284) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lDyOQ-0000VX-4w for bug-gnu-emacs@gnu.org; Sun, 21 Feb 2021 18:44:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43716) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lDyOP-0006H6-Rk for bug-gnu-emacs@gnu.org; Sun, 21 Feb 2021 18:44:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lDyOP-0006Ec-Ng for bug-gnu-emacs@gnu.org; Sun, 21 Feb 2021 18:44:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Mike Kupfer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 21 Feb 2021 23:44:01 +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.161395103623948 (code B ref 46397); Sun, 21 Feb 2021 23:44:01 +0000 Original-Received: (at 46397) by debbugs.gnu.org; 21 Feb 2021 23:43:56 +0000 Original-Received: from localhost ([127.0.0.1]:55262 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lDyOK-0006EC-4I for submit@debbugs.gnu.org; Sun, 21 Feb 2021 18:43:56 -0500 Original-Received: from shell1.rawbw.com ([198.144.192.42]:15322 ident=root) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lDyOF-0006E0-KJ for 46397@debbugs.gnu.org; Sun, 21 Feb 2021 18:43:54 -0500 Original-Received: from alto (96-95-200-133-static.hfc.comcastbusiness.net [96.95.200.133]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id 11LNhbXc020081 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 21 Feb 2021 15:43:43 -0800 (PST) (envelope-from mkupfer@alum.berkeley.edu) X-Authentication-Warning: shell1.rawbw.com: Host 96-95-200-133-static.hfc.comcastbusiness.net [96.95.200.133] claimed to be alto In-Reply-To: Your message of "Sat, 20 Feb 2021 16:36:07 -0800." X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 27.1 Content-ID: <16050.1613951017.1@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:200533 Archived-At: (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. mh-unvisit-file: this function's purpose in life is to disassociate the current buffer from the underlying file. (MH-E reuses a per-folder buffer when displaying a message.) mh-read-draft: this case is similar to mh-unvisit-file. In the relevant code path, the user's configuration allows for only a single "draft" buffer, and MH-E is cleaning up a potentially old draft buffer for reuse. mh-clean-msg-header: this one confuses me. mh-clean-msg-header edits the current buffer to reflect the user's preferences for which mail headers to display. But there are several places where mh-clean-msg-header is used, and I haven't figured out if the buffer ever has an associated file when mh-clean-msg-header is called. So I'm not even sure the call to unlock-buffer actually has any value here. 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. 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 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