unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Matt Armstrong <gmatta@gmail.com>
Cc: 46397@debbugs.gnu.org, eggert@cs.ucla.edu, craven@gmx.net
Subject: bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file
Date: Sat, 13 Feb 2021 10:28:54 +0200	[thread overview]
Message-ID: <83czx4e5h5.fsf@gnu.org> (raw)
In-Reply-To: <m2wnvcahtt.fsf@matts-mbp-2016.lan> (message from Matt Armstrong on Fri, 12 Feb 2021 17:15:42 -0800)

> From: Matt Armstrong <gmatta@gmail.com>
> Cc: 46397@debbugs.gnu.org, craven@gmx.net
> Date: Fri, 12 Feb 2021 17:15:42 -0800
> 
> One obvious issue is my inexperience in the code base. The locking logic
> all seems handled in C code, and I'm not yet very familiar with Emacs'
> particularities. Most of my multi-decade long career has been in lower
> level C++ code, so it is semi-familiar, but I haven't yet internalized
> how to think about problems in the Emacs lispy-way. I keep grasping for
> expressions of OO ideas that just aren't there, or at least aren't clear
> to me. :)

Feel free to ask questions about the internals.

> One issue is that 'unlock_file' has about 10 callers (though over half
> are from write-region).
> 
> I'm not sure how functions like 'write_region',
> 'restore-buffer-modified-p' and 'replace-buffer-contents' should be
> handling lock and unlock failures.

Why not in a unified manner?  IOW, define a single function to handle
the situation where unlocking triggers some error from lower-level
APIs such as 'unlink', and call it from unlock_file no matter what was
its caller?

> I think save-buffers-kill-terminal should be modified to leave the
> buffers in a state that won't trigger un-locking much later (after it is
> too late to do proper UI interactions). If a user opts to not save a
> buffer, then the unlock could happen immediately (and possibly surface
> an error of its own). Sound good?

I don't think I understand what you are proposing here in enough
detail.  You seem to be describing several issues together, and I
don't think I understand how you propose to solve each one of them.

> One problem with the above: currently buffers do not track whether Emacs
> thinks they hold the lock. Normally I'd think about adding a "user chose
> to ignore unlock errors" flag at that spot, but it doesn't exist.

Why would we need such a flag?  Can you show a couple of use cases
where it would be necessary?

> Instead, code attempts to re-verify lock state from the file system at
> every operation. Not even setting `create-lockfiles' to nil is enough to
> prevent Emacs from attempting to delete them. Some mechanism to record
> the user's desire to bypass lock file errors is needed.

Why is such an option needed?  If we can reasonably deal with failures
to unlock each file, wouldn't that be enough?

> There is also the case where 'kill_emacs' is called from a signal, which
> seems to proceed directly to shutdown without prompting the user to save
> buffers. For this flow, I think the only option is to "swallow" the
> errors while unlocking files. The Emacs manually even allows or this
> possibility (mentioning "if Emacs crashes..."). Sound good?

But we do ask about auto-save errors in these cases, don't we?  If so,
why not ask about locks as well?

Thanks for working on this.





  parent reply	other threads:[~2021-02-13  8:28 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-09  9:47 bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file Peter
2021-02-09 23:47 ` Matt Armstrong
2021-02-10  0:23   ` Matt Armstrong
2021-02-10 15:05     ` Eli Zaretskii
2021-02-10 19:23       ` Paul Eggert
2021-02-10 19:45         ` Eli Zaretskii
2021-02-10 22:39           ` Matt Armstrong
2021-02-12  7:43             ` Eli Zaretskii
2021-02-12  9:36               ` Paul Eggert
2021-02-12 11:33                 ` Eli Zaretskii
2021-02-12 23:59                   ` Matt Armstrong
2021-02-13  8:07                     ` Eli Zaretskii
2021-02-11 22:14         ` Matt Armstrong
2021-02-12  2:20           ` Paul Eggert
2021-02-12  7:15             ` Eli Zaretskii
2021-02-13  1:15               ` Matt Armstrong
2021-02-13  1:26                 ` Paul Eggert
2021-02-13  8:21                   ` Eli Zaretskii
2021-02-13  8:28                 ` Eli Zaretskii [this message]
2021-02-14  0:49                   ` Matt Armstrong
2021-02-14 19:22                     ` Eli Zaretskii
2021-02-14 22:16                       ` Matt Armstrong
2021-02-15 15:09                         ` Eli Zaretskii
2021-02-16  0:49                           ` Matt Armstrong
2021-02-16  1:55                             ` Paul Eggert
2021-02-16 15:06                               ` Eli Zaretskii
2021-02-16 11:53                             ` Lars Ingebrigtsen
2021-02-22 19:24                             ` bug#46397: [PATCH] " Matt Armstrong
2021-02-19 19:10                           ` Matt Armstrong
2021-02-19 19:23                             ` Eli Zaretskii
2021-02-19 21:46                               ` Matt Armstrong
2021-02-20  9:09                                 ` Eli Zaretskii
2021-02-21  0:36                                   ` Matt Armstrong
2021-02-21 23:43                                     ` Mike Kupfer
2021-02-22  1:42                                       ` Matt Armstrong
2021-03-14 18:03                                         ` Bill Wohler
2021-03-17 23:36                                           ` Matt Armstrong
2021-02-24 17:37                                     ` Matt Armstrong
2021-02-24 18:50                                       ` Eli Zaretskii
2021-03-01 16:59                                       ` Eli Zaretskii
2021-03-05 22:19                                         ` Matt Armstrong
2021-03-06  9:36                                           ` Eli Zaretskii
2021-03-06 23:39                                             ` Matt Armstrong
2021-03-07  2:50                                             ` Paul Eggert
2021-03-07  5:57                                               ` Matt Armstrong
2021-02-19 19:45                             ` Paul Eggert
2021-02-19 21:52                               ` Matt Armstrong
2021-03-08  2:18                               ` Matt Armstrong
2021-03-11 14:34                                 ` Eli Zaretskii
2021-03-17 23:49                                   ` Matt Armstrong
2021-03-17 23:51                                   ` Matt Armstrong
2021-03-20 10:43                                     ` Eli Zaretskii
2021-03-22  1:43                                       ` Matt Armstrong
2021-03-27  9:20                                         ` Eli Zaretskii
2021-02-10  0:26   ` Matt Armstrong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83czx4e5h5.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=46397@debbugs.gnu.org \
    --cc=craven@gmx.net \
    --cc=eggert@cs.ucla.edu \
    --cc=gmatta@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).