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

[Matt Armstrong <matt@rfc20.org>]

Matt Armstrong <matt@rfc20.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:

[...]

>> I think we should audit all the callers of unlock_buffer and
>> unlock_file, and see if signaling an error there is really the best
>> alternative.

[...]

Eli, no rush but I wanted to be clear that I have paused work on this
bug until I get more feedback from you.  At this point I don't have any
more avenues that I feel I can explore, and I am unsure what more you'd
like to see before we move forward with a decision here.

I'm willing to work toward any of the options I outline below, or
something new that I have not considered.

I still like my original idea of calling display-warning for all unlock
errors, essentially turning "unlock" into a best effort function at the
API level.  I think display-warning is intrusive enough that users are
unlikely to simply not notice the problem, and there are worse things
than leaving lock files around.

I could see prompting for all errors from unlock-buffer itself, but I
have concerns about it.  As my analysis showed, the unlock operation
happens in potentially thousands of call sites in Emacs core alone.
This not counting third party elisp code.  It escallates an error to a
user interaction, which defeats mechanisms like with-demoted-errors and
other uses of condition-case.

Short of my display-warning idea, I think a reasonable option is to
handle unlock errors in targeted places.  This isn't a particularly
radical idea, I think.  The only two we know to be very problematic for
users is kill-buffer and kill-emacs.

That is my summary of where the discussion is at.  Let me know how you'd
like to proceed.