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: Sat, 13 Feb 2021 10:28:54 +0200 Message-ID: <83czx4e5h5.fsf@gnu.org> References: <87h7mllgin.fsf@nexoid.at> <83a6scj745.fsf@gnu.org> <39d0e035-27b6-e2bd-daa2-747dda2c1a35@cs.ucla.edu> <83tuqhg3j9.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34997"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46397@debbugs.gnu.org, eggert@cs.ucla.edu, craven@gmx.net To: Matt Armstrong Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 13 09:30:10 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 1lAqJe-00091m-Gi for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 13 Feb 2021 09:30:10 +0100 Original-Received: from localhost ([::1]:39758 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lAqJd-0005fb-HR for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 13 Feb 2021 03:30:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60720) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lAqJW-0005fT-VI for bug-gnu-emacs@gnu.org; Sat, 13 Feb 2021 03:30:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50209) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lAqJW-0004eG-Nn for bug-gnu-emacs@gnu.org; Sat, 13 Feb 2021 03:30:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lAqJW-00039f-ID for bug-gnu-emacs@gnu.org; Sat, 13 Feb 2021 03:30: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: Sat, 13 Feb 2021 08:30: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.161320494712026 (code B ref 46397); Sat, 13 Feb 2021 08:30:02 +0000 Original-Received: (at 46397) by debbugs.gnu.org; 13 Feb 2021 08:29:07 +0000 Original-Received: from localhost ([127.0.0.1]:33522 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lAqIc-00037u-MK for submit@debbugs.gnu.org; Sat, 13 Feb 2021 03:29:06 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:42748) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lAqIa-00037M-RO for 46397@debbugs.gnu.org; Sat, 13 Feb 2021 03:29:05 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45302) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lAqIU-00043o-QX; Sat, 13 Feb 2021 03:28:58 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3816 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lAqIR-0004RR-OK; Sat, 13 Feb 2021 03:28:56 -0500 In-Reply-To: (message from Matt Armstrong on Fri, 12 Feb 2021 17:15:42 -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:199903 Archived-At: > From: Matt Armstrong > Cc: 46397@debbugs.gnu.org, craven@gmx.net > Date: Fri, 12 Feb 2021 17:15:42 -0800 > > 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. :) Feel free to ask questions about the internals. > 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. Why not in a unified manner? IOW, define a single function to handle the situation where unlocking triggers some error from lower-level APIs such as 'unlink', and call it from unlock_file no matter what was its caller? > 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? I don't think I understand what you are proposing here in enough detail. You seem to be describing several issues together, and I don't think I understand how you propose to solve each one of them. > 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. Why would we need such a flag? Can you show a couple of use cases where it would be necessary? > 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. Why is such an option needed? If we can reasonably deal with failures to unlock each file, wouldn't that be enough? > 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? But we do ask about auto-save errors in these cases, don't we? If so, why not ask about locks as well? Thanks for working on this.