[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that
From: |
Matt Armstrong |
Subject: |
bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file |
Date: |
Sun, 21 Feb 2021 17:42:38 -0800 |
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.
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, (continued)
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Lars Ingebrigtsen, 2021/02/16
- bug#46397: [PATCH] Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Matt Armstrong, 2021/02/22
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Matt Armstrong, 2021/02/19
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Eli Zaretskii, 2021/02/19
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Matt Armstrong, 2021/02/19
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Eli Zaretskii, 2021/02/20
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Matt Armstrong, 2021/02/20
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Mike Kupfer, 2021/02/21
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file,
Matt Armstrong <=
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Matt Armstrong, 2021/02/24
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Eli Zaretskii, 2021/02/24
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Paul Eggert, 2021/02/19
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Matt Armstrong, 2021/02/19
bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Matt Armstrong, 2021/02/09