From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Vincent Lefevre Newsgroups: gmane.emacs.bugs Subject: bug#13522: 24.2; save-buffer removes edited file under some conditions Date: Mon, 14 Mar 2022 16:20:53 +0100 Message-ID: <20220314152053.GB2381@cventin.lip.ens-lyon.fr> References: <87622qaszq.fsf@xvii.vinc17.org> <8735jkye2q.fsf@gnus.org> <83mthsk63c.fsf@gnu.org> <87sfrkwsy5.fsf@gnus.org> <83fsnkk4so.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31644"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.2.1+12 (1ba319cf) vl-138565 (2022-03-05) Cc: Lars Ingebrigtsen , 13522@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 14 16:21:15 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nTmVX-000813-1C for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 14 Mar 2022 16:21:15 +0100 Original-Received: from localhost ([::1]:59534 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nTmVV-000141-U5 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 14 Mar 2022 11:21:14 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:39028) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nTmVK-00011D-TO for bug-gnu-emacs@gnu.org; Mon, 14 Mar 2022 11:21:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52107) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nTmVK-0003UN-KF for bug-gnu-emacs@gnu.org; Mon, 14 Mar 2022 11:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nTmVK-0006az-CC for bug-gnu-emacs@gnu.org; Mon, 14 Mar 2022 11:21:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Vincent Lefevre Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Mar 2022 15:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13522 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 13522-submit@debbugs.gnu.org id=B13522.164727126025325 (code B ref 13522); Mon, 14 Mar 2022 15:21:02 +0000 Original-Received: (at 13522) by debbugs.gnu.org; 14 Mar 2022 15:21:00 +0000 Original-Received: from localhost ([127.0.0.1]:46004 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nTmVI-0006aO-AK for submit@debbugs.gnu.org; Mon, 14 Mar 2022 11:21:00 -0400 Original-Received: from cventin.lip.ens-lyon.fr ([140.77.13.17]:35004) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nTmVG-0006aG-AI for 13522@debbugs.gnu.org; Mon, 14 Mar 2022 11:20:58 -0400 Original-Received: from vlefevre by cventin.lip.ens-lyon.fr with local (Exim 4.95) (envelope-from ) id 1nTmVB-0004Pc-7z; Mon, 14 Mar 2022 16:20:53 +0100 Content-Disposition: inline In-Reply-To: <83fsnkk4so.fsf@gnu.org> X-Mailer-Info: https://www.vinc17.net/mutt/ X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:228377 Archived-At: On 2022-03-14 16:05:43 +0200, Eli Zaretskii wrote: > > From: Lars Ingebrigtsen > > Cc: vincent@vinc17.net, 13522@debbugs.gnu.org > > Date: Mon, 14 Mar 2022 14:43:14 +0100 > > > > Eli Zaretskii writes: > > > > > Is it "C-c to kill Emacs" as in "terminate Emacs with a fatal signal", > > > or is it "C-x C-c" as in "exit Emacs in an orderly fashion"? > > > > > > If the former, then in general killing a program when it is in the > > > middle of writing files isn't guaranteed to preserve those files. > > > > It's the former (sort of). > > > > And, yes, we make no guarantees, but the present situation doesn't seem > > optimal. The user may well hit `C-z' at the prompt and wonder where the > > file disappeared to. > > That's in the "if it hurts, don't do that" department, IMO. This is silly. Ctrl-C is *standard* to interrupt commands. When there is a risk to lose data or to get in an inconsistent state, commands should trap SIGINT (either to ignore it or to do some cleanup before exiting). Note that in any case, C-x C-c in Emacs does not replace Ctrl-C in the terminal, as with C-x C-c, Emacs quits with a zero exit status, which may not be what one wants. Example: in a "svn ci", one may want to abort the commit without losing the text written in Emacs. Ctrl-C in the terminal (where "svn ci" has been run) allows one to do that. In this bug, the issue is actually more important: When one does C-x C-s, the file has been renamed, which is bad, because the user may not choose what to do immediately, and many things can happen in the period, such as a power outage, a network outage, a crash of the machine, etc. The user may not notice the issue with the file immediately, so that he may lose the contents (or the changes, e.g. if the file is handled by a VCS). The file may also be needed by other software while the user is editing it (for instance, as backup software, or some application if this is a configuration file). > SIGINT is a fatal signal, and our response to fatal signals cannot > be too fancy. We just auto-save what we can and commit suicide. Even > that is disliked by some, who say we cannot safely do anything > non-trivial from a fatal signal handler -- and they are absolutely > right, we do stuff that invokes undefined behavior. SIGINT could be equivalent to something like C-g in Emacs + quit without saving (a backup of the current buffer can be kept), exiting with a non-zero exit status. Note that you do not need to do everything in the signal handler. In general, what is done is just to set some variable saying that SIGINT has been received. The abort of the operations is done in the main code. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)