bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file

[Matt Armstrong <matt@rfc20.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Matt Armstrong <matt@rfc20.org>
>> 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?