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: Sat, 06 Mar 2021 15:39:31 -0800 Message-ID: <87eegrn970.fsf@mdeb> References: <83sg5r276b.fsf@gnu.org> <838s7j14xc.fsf@gnu.org> <837dmq95ee.fsf@gnu.org> <87y2f1meeu.fsf@mdeb> <83pn0cwrlx.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="38327"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46397@debbugs.gnu.org, eggert@cs.ucla.edu, craven@gmx.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Mar 07 00:40: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 1lIgWn-0009rM-5z for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 07 Mar 2021 00:40:09 +0100 Original-Received: from localhost ([::1]:38426 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lIgWl-0003V6-QK for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Mar 2021 18:40:07 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42042) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lIgWg-0003Ux-0k for bug-gnu-emacs@gnu.org; Sat, 06 Mar 2021 18:40:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55219) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lIgWf-0000Ht-OS for bug-gnu-emacs@gnu.org; Sat, 06 Mar 2021 18:40:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lIgWf-00066e-Kk for bug-gnu-emacs@gnu.org; Sat, 06 Mar 2021 18:40:01 -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, 06 Mar 2021 23:40: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.161507398623441 (code B ref 46397); Sat, 06 Mar 2021 23:40:01 +0000 Original-Received: (at 46397) by debbugs.gnu.org; 6 Mar 2021 23:39:46 +0000 Original-Received: from localhost ([127.0.0.1]:38532 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIgWQ-000661-5k for submit@debbugs.gnu.org; Sat, 06 Mar 2021 18:39:46 -0500 Original-Received: from relay10.mail.gandi.net ([217.70.178.230]:44531) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIgWO-00065l-1h for 46397@debbugs.gnu.org; Sat, 06 Mar 2021 18:39:45 -0500 Original-Received: from mdeb (24-113-169-116.wavecable.com [24.113.169.116]) (Authenticated sender: matt@rfc20.org) by relay10.mail.gandi.net (Postfix) with ESMTPSA id 5FC25240004; Sat, 6 Mar 2021 23:39:34 +0000 (UTC) In-Reply-To: <83pn0cwrlx.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:201699 Archived-At: Eli Zaretskii writes: >> From: Matt Armstrong >> Cc: 46397@debbugs.gnu.org, eggert@cs.ucla.edu, craven@gmx.net >> Date: Fri, 05 Mar 2021 14:19:53 -0800 >> >> > As for the tests you posted: too many of them rely on Posix file >> > modes, and thus will probably either fail or be unable to provide >> > meaningful testing on MS-Windows. Can we please augment that by tests >> > that create unlocking problems by, e.g., running a shell command to >> > remove or rename or otherwise sabotage the lock file, so that the new >> > functionality could be meaningfully tested on Windows as well? >> >> I have not been able to come up with a way to achieve what you ask for. > > I'm not yet sure I understand why. I ask several questions about this > below. [...] > I'm asking what is the difference, from the file-locking POV, between > an inaccessible directory and a directory that doesn't exist? in both > cases, the directory and a lock file inside it are "inaccessible", > right? So would we be able to make the same or similar tests by > deleting or renaming the directory with the lock file, as we do by > making the directory inaccessible? This relates to your objection to the handling of ENOTDIR that Paul added early on in this bug. If you recall, he changed filelock.c to treat ENOTDIR equivalently to ENOENT, at least in the code path taken by `unlock-file'. If we revert that change, then it again becomes possible to induce an `unlock-file' error by attempting to unlock a modified buffer whose `buffer-file-truename' names a non-existent directory. My guess is that this would be portable to MS-Windows. The only way it wouldn't is if the MS-Windows implementation of unlock() returns ENOENT if the directory along the path does not exist. >> What I've done is make the tests skip themselves when `set-file-mode' on >> the test's temporary directory appears to not work. When I test this on >> an ext2 file system the tests complete. When I test this on a FAT and >> NTFS file system (set up as a ramdisk on GNU/Linux), the tests skip >> themselves. > > That's exactly the issue: I'd like the tests to not be skipped on > Windows, at least some of them, so that the underlying functionality > could be tested there as well. Reverting Paul's ENOTDIR change to the unlock code path would give us a good option for testing this in a portable way. I am, given that the plan is to treat all such errors as `display-warning' events, and the relative rarity of the situation coming up in practice, it feels like the simplest way to exercise this kind of error in a portable test. Paul, would you be okay with that approach?