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: Thu, 11 Mar 2021 16:34:53 +0200 Message-ID: <83h7lhn4he.fsf@gnu.org> References: <87wnuio0ah.fsf@mdeb> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36309"; 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 Thu Mar 11 15:36:09 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 1lKMQ5-0009Jm-1q for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 11 Mar 2021 15:36:09 +0100 Original-Received: from localhost ([::1]:39678 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lKMQ4-0002AF-4a for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 11 Mar 2021 09:36:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38386) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lKMPy-00029y-Sk for bug-gnu-emacs@gnu.org; Thu, 11 Mar 2021 09:36:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41369) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lKMPy-0003jF-L7 for bug-gnu-emacs@gnu.org; Thu, 11 Mar 2021 09:36:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lKMPy-0000bG-Ie for bug-gnu-emacs@gnu.org; Thu, 11 Mar 2021 09:36: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: Thu, 11 Mar 2021 14:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46397 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 46397-submit@debbugs.gnu.org id=B46397.16154733042235 (code B ref 46397); Thu, 11 Mar 2021 14:36:02 +0000 Original-Received: (at 46397) by debbugs.gnu.org; 11 Mar 2021 14:35:04 +0000 Original-Received: from localhost ([127.0.0.1]:52915 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lKMP2-0000Zz-AZ for submit@debbugs.gnu.org; Thu, 11 Mar 2021 09:35:04 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:48538) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lKMP0-0000ZM-28 for 46397@debbugs.gnu.org; Thu, 11 Mar 2021 09:35:02 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40666) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lKMOt-0002xa-SO; Thu, 11 Mar 2021 09:34:55 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1482 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lKMOq-0002B1-B9; Thu, 11 Mar 2021 09:34:53 -0500 In-Reply-To: <87wnuio0ah.fsf@mdeb> (message from Matt Armstrong on Sun, 07 Mar 2021 18:18:46 -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:202064 Archived-At: > From: Matt Armstrong > Cc: 46397@debbugs.gnu.org, craven@gmx.net > Date: Sun, 07 Mar 2021 18:18:46 -0800 > > It turns out that naming a directory the same as the would-be lock file > suffices to induce errors in a portable way. > > I've updated the (substantially simplified) test in patch 0001, > incorporating Eli's feedback. > > Patch 0002 implements the handling of unlock errors as warnings by way > of a userlock.el function. I figure that function would be a handy hook > for people to use with `debug-on-entry', if they want. > > Both ready for review now. Thanks, I have just two minor comments: . I'd prefer a slightly different warning text, see below . We need this change to be reflected in NEWS and perhaps in the manual > Things I noticed: > > a) if a buffer becomes unmodified by way of `undo' it is unlocked > twice, causing two warnings. > b) the file errors generated contain the original file name, not the > lock file name. > > I am treating both of of those things as not worth fixing, at least for > now. Right, I agree. > +(defun userlock--handle-unlock-error (err) > + "Report an error ERR that occurred while unlocking a file." > + (display-warning > + '(unlock-file) > + (message "Error unlocking file, proceeding as if unlocked: %s" > + (error-message-string err)) I think "proceeding as if unlocked" may be slightly confusing, especially for non-native English speakers. How about this instead: Error unlocking file %s, ignored Thanks.