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

[Matt Armstrong]

Mike Kupfer <mkupfer@alum.berkeley.edu> writes:

> (Adding Bill Wohler, who has a better grasp than I about why MH-E does
> some things.)
>
> Matt Armstrong wrote:
>
>> 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.
> [...]
>>      * lisp/mh-e/mh-show.el (mh-clean-msg-header, mh-unvisit-file):
>>        hard to say, very old code...
>>      * lisp/mh-e/mh-comp.el (mh-read-draft): ditto.
>
> I'm not sure I completely understanding the logic behind those calls to
> unlock-buffer, but I'll take a stab at it.

[...]

Thanks for those analysis Mike.  They make sense to me.


> But to Eli's question, I think a signal is fine for MH-E if the
> lockfile can't be removed for some reason.  An uncaught signal could
> leave the current buffer in an odd state, but the user can simply kill
> the buffer and retry whatever operation she had attempted.

Yes, and this bug is at least in part about the behavior of
`kill-buffer' when faced with the same issue.  That and `kill-emacs'.


> Or if the buffer has something that is worth saving, the user can
> attempt to save the buffer somewhere, perhaps a different filesystem
> (e.g., if the original filesystem went read-only due to the OS
> detecting a problem).

I think the "buffer has something worth saving" case is not a concern.

The calls to `unlock-buffer' all occur after the buffer contents have
been saved, or otherwise marked as unmodified, or, in the case of
`kill-buffer', after the user has chosen to not save a modified buffer.


> I don't understand the proposal for unlock-buffer (or something under
> it) to prompt the user.  IIUC, the proposal is for a prompt like
>
>> /tmp/x/y lock is invalid; assume unlocked? (yes or no)
>
> I assume that if the user responds with "yes", unlock-buffer returns
> and the caller is none the wiser.  If the user responds with "no",
> what happens?
>
> mike

I think under the current idea, in the case of `kill-buffer', answering
"no" from the prompt the buffer un-killed.  I think the technical
mechanism would be to either re-signal the underlying 'file-error or
signal a new 'unlock-error that contains similar information.