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: Fri, 12 Feb 2021 17:15:42 -0800 Message-ID: References: <87h7mllgin.fsf@nexoid.at> <83a6scj745.fsf@gnu.org> <39d0e035-27b6-e2bd-daa2-747dda2c1a35@cs.ucla.edu> <83tuqhg3j9.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34100"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46397@debbugs.gnu.org, craven@gmx.net To: Eli Zaretskii , Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 13 02:56:48 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 1lAkAy-0008lJ-BB for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 13 Feb 2021 02:56:48 +0100 Original-Received: from localhost ([::1]:51336 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lAkAx-0002LS-Dq for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 12 Feb 2021 20:56:47 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35700) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lAk9H-0001iV-2m for bug-gnu-emacs@gnu.org; Fri, 12 Feb 2021 20:55:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49958) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lAk9G-0001KQ-SE for bug-gnu-emacs@gnu.org; Fri, 12 Feb 2021 20:55:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lAjYU-0007P1-0k for bug-gnu-emacs@gnu.org; Fri, 12 Feb 2021 20:17: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: Sat, 13 Feb 2021 01:17: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.161317899928421 (code B ref 46397); Sat, 13 Feb 2021 01:17:01 +0000 Original-Received: (at 46397) by debbugs.gnu.org; 13 Feb 2021 01:16:39 +0000 Original-Received: from localhost ([127.0.0.1]:33254 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lAjXs-0007Nt-LM for submit@debbugs.gnu.org; Fri, 12 Feb 2021 20:16:39 -0500 Original-Received: from relay10.mail.gandi.net ([217.70.178.230]:41631) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lAjXX-0007Mw-1G for 46397@debbugs.gnu.org; Fri, 12 Feb 2021 20:16:18 -0500 Original-Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com [24.113.169.116]) (Authenticated sender: matt@rfc20.org) by relay10.mail.gandi.net (Postfix) with ESMTPSA id E3C16240002; Sat, 13 Feb 2021 01:15:45 +0000 (UTC) In-Reply-To: <83tuqhg3j9.fsf@gnu.org> 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:199894 Archived-At: Eli Zaretskii writes: >> Cc: 46397@debbugs.gnu.org, craven@gmx.net >> From: Paul Eggert >> Date: Thu, 11 Feb 2021 18:20:44 -0800 >> >> On 2/11/21 2:14 PM, Matt Armstrong wrote: >> >> > The issue isn't confined to exiting Emacs. It appears that once in a >> > "tricky situation where the file can't be unlocked for whatever reason" >> > Emacs will refuse to kill the buffer because unlock_file() signals an >> > error. >> >> kill-buffer already asks the user something like "Buffer XXX modified; >> kill anyway? (yes or no)" when killing a buffer that's been changed >> without being saved. Perhaps it should also ask "File XXX cannot be >> unlocked; kill buffer anyway? (yes or no)" if the file can't be unlocked. >> >> > Note that shut_down_emacs() calls Fdo_auto_save() just before >> > unlock_all_files() and that call succeeds. Fdo_auto_save() also calls >> > report_file_errno, throwing an errno 13 (Permission denied), but that >> > recovers and continues. >> >> Presumably shut_down_emacs should recover and continue if >> unlock_all_files fails when it directly calls unlock_all_files. > > That all is true, but I think we should provide for recovery in a way > that will work with _any_ command that calls unlock_file or > unlock_all_files. Not just these two instances. See my other message > about this. Eli, I looked a bit at finding a general solution. One obvious issue is my inexperience in the code base. The locking logic all seems handled in C code, and I'm not yet very familiar with Emacs' particularities. Most of my multi-decade long career has been in lower level C++ code, so it is semi-familiar, but I haven't yet internalized how to think about problems in the Emacs lispy-way. I keep grasping for expressions of OO ideas that just aren't there, or at least aren't clear to me. :) One issue is that 'unlock_file' has about 10 callers (though over half are from write-region). I'm not sure how functions like 'write_region', 'restore-buffer-modified-p' and 'replace-buffer-contents' should be handling lock and unlock failures. I think save-buffers-kill-terminal should be modified to leave the buffers in a state that won't trigger un-locking much later (after it is too late to do proper UI interactions). If a user opts to not save a buffer, then the unlock could happen immediately (and possibly surface an error of its own). Sound good? One problem with the above: currently buffers do not track whether Emacs thinks they hold the lock. Normally I'd think about adding a "user chose to ignore unlock errors" flag at that spot, but it doesn't exist. Instead, code attempts to re-verify lock state from the file system at every operation. Not even setting `create-lockfiles' to nil is enough to prevent Emacs from attempting to delete them. Some mechanism to record the user's desire to bypass lock file errors is needed. There is also the case where 'kill_emacs' is called from a signal, which seems to proceed directly to shutdown without prompting the user to save buffers. For this flow, I think the only option is to "swallow" the errors while unlocking files. The Emacs manually even allows or this possibility (mentioning "if Emacs crashes..."). Sound good? You have suggested showing a prompt. What question would it ask? I am having trouble imagining ways of making the situation clear to the user. There are also many situations: - unable to determine if Emacs has the lock - unable to acquire the lock - unable to release the lock None of these are questions. What do we expect the user to actually understand and answer to from these prompts? Or, is issuing a message sufficient? A message would certainly simplify things.