GNU bug report logs - #23276
25.0.92; Crash in auto-revert when file no longer present

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23276 in the body.
You can then email your comments to 23276 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Anders Lindgren <andlind <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.92; Crash in auto-revert when file no longer present
Date: Tue, 12 Apr 2016 13:07:48 +0200

[Message part 1 (text/plain, inline)]

Hi!

I just had auto-revert crash on me... (Emacs 25.0.92 on Windows.
`debug-on-error' is t.)

I had a file open in Emacs that was rewritten over and over again by an
external process. My guess is that Emacs decides that it should be
reverted, but when it actually reads the file, it is no longer present.

I would suggest that auto-revert silently ignores this error.

This is the backtrace (with simplified paths):

Debugger entered--Lisp error: (error "File e:/file.txt no longer exists!")
  signal(error ("File e:/file.txt no longer exists!"))
  error("File %s no longer exists!" "e:/file.txt")
  revert-buffer-insert-file-contents--default-function("e:/file.txt" nil)
  revert-buffer--default(ignore-auto dont-ask)
  revert-buffer(ignore-auto dont-ask preserve-modes)
  auto-revert-handler()
  auto-revert-buffers()
  apply(auto-revert-buffers nil)
  timer-event-handler([t 22284 48416 597024 5 auto-revert-buffers nil
nil 400000])

Sincerely,
    Anders Lindgren


In GNU Emacs 25.0.92.1 (i686-w64-mingw32)
 of 2016-03-21 built on LAPHROAIG
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Configured using:
 'configure --host=i686-w64-mingw32 --without-dbus
 --without-compress-install CFLAGS=-static'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: SVE
  locale-coding-system: cp1252

Major mode: Compilation

Minor modes in effect:
  shell-dirtrack-mode: t
  dynamic-spaces-global-mode: t
  char-font-lock-global-mode: t
  global-auto-revert-mode: t
  global-cwarn-mode: t
  preproc-font-lock-global-mode: t
  highlight-doxygen-global-mode: t
  lisp-extra-font-lock-global-mode: t
  global-edit-server-edit-mode: t
  highlight2clipboard-mode: t
  minibuffer-electric-file-mode: t
  recentf-mode: t
  msb-mode: t
  multicolumn-global-mode: t
  display-time-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Auto-saving...done
Saving file
e:/src/Mystro-430/430-iasm/test/testcases/checklist/iasm/outr.c...
Wrote e:/src/Mystro-430/430-iasm/test/testcases/checklist/iasm/outr.c
Mark set
funcall-interactively: End of buffer [2 times]
Mark set
Compilation finished
Restarting server
next-line: End of buffer [6 times]
Making completion list... [2 times]

Load-path shadows:
e:/home/AndersL/emacs/lisp/table hides e:/Program
Files/emacs-25.0.92/share/emacs/25.0.92/lisp/textmodes/table
e:/home/AndersL/emacs/src/asm-mode-new/src/asm-mode hides e:/Program
Files/emacs-25.0.92/share/emacs/25.0.92/lisp/progmodes/asm-mode
e:/home/AndersL/.emacs.d/elpa/25.0.92.x/helm-core-20160331.118/helm-multi-match
hides
e:/home/AndersL/.emacs.d/elpa/25.0.92.x/helm-20160331.118/helm-multi-match
e:/home/AndersL/emacs/src/misc/c-clean-buffer hides
e:/src/emacs-modules/IAR/c-clean-buffer
e:/home/AndersL/emacs/lisp/wikipedia-mode hides
e:/src/emacs-modules/lisp/wikipedia-mode
e:/home/AndersL/emacs/src/misc/stdify hides e:/src/emacs-modules/lisp/stdify
e:/Program Files/emacs-25.0.92/share/emacs/25.0.92/lisp/progmodes/ruby-mode
hides e:/src/emacs-modules/lisp/ruby-mode
e:/home/AndersL/emacs/src/misc/preproc hides
e:/src/emacs-modules/lisp/preproc
e:/home/AndersL/emacs/src/misc/preproc-indent hides
e:/src/emacs-modules/lisp/preproc-indent
e:/home/AndersL/emacs/lisp/gnuserv hides e:/src/emacs-modules/lisp/gnuserv
e:/home/AndersL/emacs/lisp/dsvn hides e:/src/emacs-modules/lisp/dsvn
e:/home/AndersL/emacs/src/misc/ctypes hides e:/src/emacs-modules/lisp/ctypes
e:/home/AndersL/emacs/lisp/column-marker hides
e:/src/emacs-modules/lisp/column-marker
e:/home/AndersL/emacs/lisp/cmake-mode hides
e:/src/emacs-modules/lisp/cmake-mode
e:/home/AndersL/emacs/src/misc/c-indent-operator hides
e:/src/emacs-modules/lisp/c-indent-operator
e:/home/AndersL/emacs/src/misc/c-electric-operator hides
e:/src/emacs-modules/lisp/c-electric-operator

Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec epg
epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mail-utils
dired-aux t2-checklist yaml-mode font-lock-studio make-mode macros
t2-config cperl-mode vc-annotate burs-mode cc-langs add-log log-view
pcvs-util sh-script executable ffap url-parse auth-source mm-util
mail-prsvr password-cache url-vars ispell rect debug vc shell grep
compile pulse cmake-font-lock cmake-mode iar-trace-mode tags-extra
org-element org-rmail org-mhe org-irc org-info org-gnus gnus-util
org-docview doc-view jka-compr image-mode org-bibtex bibtex org-bbdb
org-w3m org org-macro org-footnote org-pcomplete pcomplete org-list
org-faces org-entities noutline outline org-version ob-emacs-lisp ob
ob-tangle ob-ref ob-lob ob-table ob-exp org-src ob-keys ob-comint
ob-core ob-eval org-compat org-macs org-loaddefs format-spec cal-menu
calendar cal-loaddefs asm-mode eieio-opt speedbar sb-image ezimage
dframe find-func misearch multi-isearch apropos help-fns dabbrev
macrostep-c subr-x cmacexp macrostep pp end-of-buffer-log cap-words
superword subword doxygen c-align-operands ruby-mode smie thingatpt
vc-dispatcher cmake-cache iartags-visit-tags dired etags xref cl-seq
project eieio byte-opt bytecomp byte-compile cl-extra help-mode cconv
eieio-core ps-print ps-def lpr iaremacs-init t2-log-mode
t2-show-config-mode lockdir project-name view-all-targets edg-mode
site-start c-electric-operator vc-svn server dynamic-spaces
char-font-lock autorevert filenotify folding-isearch folding tail-mode
view cwarn cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align
cc-engine cc-vars cc-defs preproc-font-lock objc-font-lock
highlight-doxygen lisp-extra-font-lock edit-server highlight2clipboard
htmlize ange-ftp comint ansi-color ring paren mic-paren iso-insert
minibuf-elfile recentf tree-widget wid-edit msb multicolumn edmacro
kmacro easy-mmode autoload lisp-mnt finder-inf package easymenu time
lindydancer-theme old-emacs-support cl-macs derived advice cl gv
cl-loaddefs pcase cl-lib time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp
disp-table w32-win w32-vars term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote w32notify w32 multi-tty
make-network-process emacs)

Memory information:
((conses 8 1762813 181390)
 (symbols 32 56055 44)
 (miscs 32 2037 11084)
 (strings 16 204630 26517)
 (string-bytes 1 6691609)
 (vectors 8 47367)
 (vector-slots 4 1844109 23864)
 (floats 8 675 741)
 (intervals 28 276896 223)
 (buffers 520 201))

[Message part 2 (text/html, inline)]

Message #8 received at 23276 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: 23276 <at> debbugs.gnu.org
Subject: Re: bug#23276: 25.0.92;
 Crash in auto-revert when file no longer present
Date: Tue, 12 Apr 2016 18:16:53 +0300

> Date: Tue, 12 Apr 2016 13:07:48 +0200
> From: Anders Lindgren <andlind <at> gmail.com>
> 
> I just had auto-revert crash on me... (Emacs 25.0.92 on Windows. `debug-on-error' is t.)

I don't see any crash, just an error that was signaled.  Am I missing
something?

> I had a file open in Emacs that was rewritten over and over again by an external process. My guess is that
> Emacs decides that it should be reverted, but when it actually reads the file, it is no longer present.
> 
> I would suggest that auto-revert silently ignores this error.

Ignore and empty the buffer, or ignore and leave it at its previous
contents?

Message #11 received at 23276 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23276 <at> debbugs.gnu.org, Anders Lindgren <andlind <at> gmail.com>
Subject: Re: bug#23276: 25.0.92;
 Crash in auto-revert when file no longer present
Date: Tue, 12 Apr 2016 18:14:55 +0200

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

>> Date: Tue, 12 Apr 2016 13:07:48 +0200
>> From: Anders Lindgren <andlind <at> gmail.com>
>> 
>> I just had auto-revert crash on me... (Emacs 25.0.92 on Windows. `debug-on-error' is t.)
>
> I don't see any crash, just an error that was signaled.  Am I missing
> something?

No, it's an error. I guess Anders meant "crash *of* auto-revert"
 
>> I had a file open in Emacs that was rewritten over and over again by an external process. My guess is that
>> Emacs decides that it should be reverted, but when it actually reads the file, it is no longer present.
>> 
>> I would suggest that auto-revert silently ignores this error.
>
> Ignore and empty the buffer, or ignore and leave it at its previous
> contents?

The latter one. Anders has explained me that there is a design goal of
auto-revert, to leave the buffer unchanged in such cases. A user could
have deleted the file by accident, and she could use the unchanged
buffer for restoring the file.

I'll try to prepare a patch. If it is as simple as I do expect, it could
go to the emacs-25 branch.

Best regards, Michael.

Message #14 received at 23276 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: 23276 <at> debbugs.gnu.org
Subject: Re: bug#23276: 25.0.92;
 Crash in auto-revert when file no longer present
Date: Sat, 16 Apr 2016 20:44:18 +0200

Anders Lindgren <andlind <at> gmail.com> writes:

> Hi!

Hi,

> I just had auto-revert crash on me... (Emacs 25.0.92 on Windows.
> `debug-on-error' is t.)
>
> I had a file open in Emacs that was rewritten over and over again by
> an external process. My guess is that Emacs decides that it should be
> reverted, but when it actually reads the file, it is no longer
> present.

I've tried to write a test case for this, but I've failed. Do you have a
recipe to provoke this error?

> I would suggest that auto-revert silently ignores this error.

Yep. Does anybody object to install the following patch in the emacs-25 branch?

--8<---------------cut here---------------start------------->8---
*** /home/albinus/src/emacs-25/lisp/autorevert.el.~f3653ec446ed95404889cf16c67b2d96b3955f52~	2016-04-16 20:38:55.247491182 +0200
--- /home/albinus/src/emacs-25/lisp/autorevert.el	2016-04-16 20:36:29.485457375 +0200
***************
*** 684,690 ****
          ;; not to forget that.  This gives undesirable results when
          ;; the file's mode changes, but that is less common.
          (let ((buffer-read-only buffer-read-only))
!           (revert-buffer 'ignore-auto 'dont-ask 'preserve-modes)))
        (when buffer-file-name
          (when eob (goto-char (point-max)))
          (dolist (window eoblist)
--- 684,691 ----
          ;; not to forget that.  This gives undesirable results when
          ;; the file's mode changes, but that is less common.
          (let ((buffer-read-only buffer-read-only))
!           (ignore-errors
!             (revert-buffer 'ignore-auto 'dont-ask 'preserve-modes))))
        (when buffer-file-name
          (when eob (goto-char (point-max)))
          (dolist (window eoblist)
--8<---------------cut here---------------end--------------->8---

> Sincerely,
> Anders Lindgren

Best regards, Michael.

Message #17 received at 23276 <at> debbugs.gnu.org (full text, mbox):

From: Anders Lindgren <andlind <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 23276 <at> debbugs.gnu.org
Subject: Re: bug#23276: 25.0.92;
 Crash in auto-revert when file no longer present
Date: Sat, 16 Apr 2016 20:55:19 +0200

[Message part 1 (text/plain, inline)]

Hi!


> > I had a file open in Emacs that was rewritten over and over again by
> > an external process. My guess is that Emacs decides that it should be
> > reverted, but when it actually reads the file, it is no longer
> > present.
>
> I've tried to write a test case for this, but I've failed. Do you have a
> recipe to provoke this error?
>

Unfortunately, no. And I don't see how it would be possible to write a test
for this either, as the file must be removed after auto-revert decides that
it should be reverted and before the actual revert takes place.

In real-life, I see it a couple of times each week. However, in my Emacs I
have opened files associated with processes that erase and rewrite them,
say, every ten seconds.

    Anders

[Message part 2 (text/html, inline)]

Message #20 received at 23276 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 23276 <at> debbugs.gnu.org, andlind <at> gmail.com
Subject: Re: bug#23276: 25.0.92;
 Crash in auto-revert when file no longer present
Date: Sat, 16 Apr 2016 22:00:32 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Date: Sat, 16 Apr 2016 20:44:18 +0200
> Cc: 23276 <at> debbugs.gnu.org
> 
> Does anybody object to install the following patch in the emacs-25 branch?
> 
> --8<---------------cut here---------------start------------->8---
> *** /home/albinus/src/emacs-25/lisp/autorevert.el.~f3653ec446ed95404889cf16c67b2d96b3955f52~	2016-04-16 20:38:55.247491182 +0200
> --- /home/albinus/src/emacs-25/lisp/autorevert.el	2016-04-16 20:36:29.485457375 +0200
> ***************
> *** 684,690 ****
>           ;; not to forget that.  This gives undesirable results when
>           ;; the file's mode changes, but that is less common.
>           (let ((buffer-read-only buffer-read-only))
> !           (revert-buffer 'ignore-auto 'dont-ask 'preserve-modes)))
>         (when buffer-file-name
>           (when eob (goto-char (point-max)))
>           (dolist (window eoblist)
> --- 684,691 ----
>           ;; not to forget that.  This gives undesirable results when
>           ;; the file's mode changes, but that is less common.
>           (let ((buffer-read-only buffer-read-only))
> !           (ignore-errors
> !             (revert-buffer 'ignore-auto 'dont-ask 'preserve-modes))))
>         (when buffer-file-name
>           (when eob (goto-char (point-max)))
>           (dolist (window eoblist)
> --8<---------------cut here---------------end--------------->8---

It should have a comment explaining why errors are being ignored.

And I still am not convinced that deleting a file under auto-revert
shouldn't erase its buffer.  Otherwise, it sounds like just
half-auto-revert to me.  Would we keep the buffer non-empty if the
file existed but was empty?

Thanks.

Message #23 received at 23276 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23276 <at> debbugs.gnu.org, andlind <at> gmail.com
Subject: Re: bug#23276: 25.0.92;
 Crash in auto-revert when file no longer present
Date: Sat, 16 Apr 2016 22:35:17 +0200

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

> It should have a comment explaining why errors are being ignored.

OK.

> And I still am not convinced that deleting a file under auto-revert
> shouldn't erase its buffer.  Otherwise, it sounds like just
> half-auto-revert to me.

What if we simply disable auto-revert-mode in this case? The user sees
that the lighter "ARev" has been removed, and she knows that things have
changed.

> Would we keep the buffer non-empty if the file existed but was empty?

Yes.

> Thanks.

Best regards, Michael.

Message #26 received at 23276 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: 23276 <at> debbugs.gnu.org
Subject: Re: bug#23276: 25.0.92;
 Crash in auto-revert when file no longer present
Date: Sat, 16 Apr 2016 22:56:15 +0200

Anders Lindgren <andlind <at> gmail.com> writes:

> Hi!

Hi,

>     I've tried to write a test case for this, but I've failed. Do you
>     have a recipe to provoke this error?
>
>
> Unfortunately, no. And I don't see how it would be possible to write a
> test for this either, as the file must be removed after auto-revert
> decides that it should be reverted and before the actual revert takes
> place.

I found a way. Temporarily, I add a function to before-revert-hook,
which deletes the file. This provokes the error.

> Anders

Best regards, Michael.

Message #29 received at 23276 <at> debbugs.gnu.org (full text, mbox):

From: Anders Lindgren <andlind <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23276 <at> debbugs.gnu.org, Michael Albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#23276: 25.0.92;
 Crash in auto-revert when file no longer present
Date: Sat, 16 Apr 2016 22:56:41 +0200

[Message part 1 (text/plain, inline)]

>
> And I still am not convinced that deleting a file under auto-revert
> shouldn't erase its buffer.  Otherwise, it sounds like just
> half-auto-revert to me.  Would we keep the buffer non-empty if the
> file existed but was empty?
>

When I originally wrote auto-revert mode I decided that Emacs should not
clear a buffer when the corresponding file was removed, as a safeguard
against a file accidentally being removed. Today, I still think that is the
correct way to handle this situation.

The current patch handles a special case when the file is removed after it
has been decided that it should be reverted, but right before the actual
revert -- it should be treated just like a normal file delete.

I think disabling auto-revert mode is not correct way to handle this -- the
file might be temporary removed by, say, a version control system and might
reappear a moment later, in which case we want it to be reverted into Emacs.

    -- Anders

[Message part 2 (text/html, inline)]

Message #32 received at 23276 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: 23276 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#23276: 25.0.92;
 Crash in auto-revert when file no longer present
Date: Sat, 16 Apr 2016 23:30:49 +0200

Anders Lindgren <andlind <at> gmail.com> writes:

> I think disabling auto-revert mode is not correct way to handle this -
> - the file might be temporary removed by, say, a version control
> system and might reappear a moment later, in which case we want it to
> be reverted into Emacs.

I've just checked: the current implementation deactivates auto-revert-mode
already in this case. At least file notification is disabled (due to the
`deleted' file notification event). Polling shall still be work, to be checked.

> -- Anders

Best regards, Michael.

Message #35 received at 23276 <at> debbugs.gnu.org (full text, mbox):

From: John Wiegley <jwiegley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23276 <at> debbugs.gnu.org, Michael Albinus <michael.albinus <at> gmx.de>,
 andlind <at> gmail.com
Subject: Re: bug#23276: 25.0.92;
 Crash in auto-revert when file no longer present
Date: Sat, 16 Apr 2016 18:54:17 -0700

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

> And I still am not convinced that deleting a file under auto-revert
> shouldn't erase its buffer. Otherwise, it sounds like just half-auto-revert
> to me. Would we keep the buffer non-empty if the file existed but was empty?

I would not want it to erase the buffer. Countless have been the times that
I've been working on a project, and an unbridled rm took away code from the
disk which I was very grateful to find was still in a buffer.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Message #38 received at 23276 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: John Wiegley <jwiegley <at> gmail.com>
Cc: 23276 <at> debbugs.gnu.org, michael.albinus <at> gmx.de, andlind <at> gmail.com
Subject: Re: bug#23276: 25.0.92;
 Crash in auto-revert when file no longer present
Date: Sun, 17 Apr 2016 05:39:36 +0300

> From: John Wiegley <jwiegley <at> gmail.com>
> Cc: Michael Albinus <michael.albinus <at> gmx.de>,  23276 <at> debbugs.gnu.org,  andlind <at> gmail.com
> Date: Sat, 16 Apr 2016 18:54:17 -0700
> 
> >>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > And I still am not convinced that deleting a file under auto-revert
> > shouldn't erase its buffer. Otherwise, it sounds like just half-auto-revert
> > to me. Would we keep the buffer non-empty if the file existed but was empty?
> 
> I would not want it to erase the buffer. Countless have been the times that
> I've been working on a project, and an unbridled rm took away code from the
> disk which I was very grateful to find was still in a buffer.

How is it different from clobbering a file by making it empty?

Don't we have a variant of auto-revert that never shrinks the buffer?

Message #41 received at 23276 <at> debbugs.gnu.org (full text, mbox):

From: John Wiegley <jwiegley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23276 <at> debbugs.gnu.org, michael.albinus <at> gmx.de, andlind <at> gmail.com
Subject: Re: bug#23276: 25.0.92;
 Crash in auto-revert when file no longer present
Date: Sat, 16 Apr 2016 19:53:02 -0700

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

>> I would not want it to erase the buffer. Countless have been the times that
>> I've been working on a project, and an unbridled rm took away code from the
>> disk which I was very grateful to find was still in a buffer.

> How is it different from clobbering a file by making it empty?

I'm not sure, but I never clobber files that way...

> Don't we have a variant of auto-revert that never shrinks the buffer?

I think if it's significantly reduced, it does warn. But I'm not sure what
that's based on.

The current behavior, whatever it is, does not lose contents that get
accidentally deleted from disk.  I'm not sure what happens if you cat
/dev/null onto your code.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Message #44 received at 23276 <at> debbugs.gnu.org (full text, mbox):

From: John Mastro <john.b.mastro <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: John Wiegley <jwiegley <at> gmail.com>, michael.albinus <at> gmx.de,
 andlind <at> gmail.com, 23276 <at> debbugs.gnu.org
Subject: Re: bug#23276: 25.0.92;
 Crash in auto-revert when file no longer present
Date: Sat, 16 Apr 2016 19:57:12 -0700

Eli Zaretskii <eliz <at> gnu.org> wrote:
>> I would not want it to erase the buffer. Countless have been the times that
>> I've been working on a project, and an unbridled rm took away code from the
>> disk which I was very grateful to find was still in a buffer.
>
> How is it different from clobbering a file by making it empty?
>
> Don't we have a variant of auto-revert that never shrinks the buffer?

Speaking purely as a user, I think a case can be made that it really is
different. We could say:

    If the file exists, auto-revert updates the buffer based on its
    (possibly empty) contents. If the file no longer exists, then there
    is nothing for auto-revert to do, so it does not modify the buffer.

However, Michael mentioned in a previous message that the buffer would
also be left non-empty if the file existed but was empty:

Michael Albinus <michael.albinus <at> gmx.de> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>> Would we keep the buffer non-empty if the file existed but was empty?
>
> Yes.

That seems less conceptually clear to me, though I can imagine
cases where it would be more convenient.

-- 
                John

Message #47 received at 23276 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: John Mastro <john.b.mastro <at> gmail.com>
Cc: John Wiegley <jwiegley <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>,
 andlind <at> gmail.com, 23276 <at> debbugs.gnu.org
Subject: Re: bug#23276: 25.0.92;
 Crash in auto-revert when file no longer present
Date: Sun, 17 Apr 2016 10:52:52 +0200

John Mastro <john.b.mastro <at> gmail.com> writes:

> Speaking purely as a user, I think a case can be made that it really is
> different. We could say:
>
>     If the file exists, auto-revert updates the buffer based on its
>     (possibly empty) contents. If the file no longer exists, then there
>     is nothing for auto-revert to do, so it does not modify the buffer.
>
> However, Michael mentioned in a previous message that the buffer would
> also be left non-empty if the file existed but was empty:

There was a blackout, when I wrote this. I meant it exactly as you have
summarized above. Sorry.

We shall update the documentation, and precise it with your wording.

Best regards, Michael.

Message #50 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Óscar Fuentes <ofv <at> wanadoo.es>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#23276: 25.0.92;
 Crash in auto-revert when file no longer present
Date: Sun, 17 Apr 2016 15:20:22 +0200

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

>> > And I still am not convinced that deleting a file under auto-revert
>> > shouldn't erase its buffer. Otherwise, it sounds like just
>> > half-auto-revert to me. Would we keep the buffer non-empty if the
>> > file existed but was empty?
>> 
>> I would not want it to erase the buffer. Countless have been the times that
>> I've been working on a project, and an unbridled rm took away code from the
>> disk which I was very grateful to find was still in a buffer.
>
> How is it different from clobbering a file by making it empty?

$ echo hello > foo.txt

$ emacs -Q foo.txt &

M-x auto-revert-mode

$ echo -n > foo.txt

M-x undo

Clobbering a file doesn't imply that you lose its previous contents.

Message #53 received at 23276 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Óscar Fuentes <ofv <at> wanadoo.es>
Cc: 23276 <at> debbugs.gnu.org
Subject: Re: bug#23276: 25.0.92;
 Crash in auto-revert when file no longer present
Date: Sun, 17 Apr 2016 18:16:28 +0300

> From: Óscar Fuentes <ofv <at> wanadoo.es>
> Date: Sun, 17 Apr 2016 15:20:22 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> > And I still am not convinced that deleting a file under auto-revert
> >> > shouldn't erase its buffer. Otherwise, it sounds like just
> >> > half-auto-revert to me. Would we keep the buffer non-empty if the
> >> > file existed but was empty?
> >> 
> >> I would not want it to erase the buffer. Countless have been the times that
> >> I've been working on a project, and an unbridled rm took away code from the
> >> disk which I was very grateful to find was still in a buffer.
> >
> > How is it different from clobbering a file by making it empty?
> 
> $ echo hello > foo.txt
> 
> $ emacs -Q foo.txt &
> 
> M-x auto-revert-mode
> 
> $ echo -n > foo.txt
> 
> M-x undo

How is this relevant to the issue at hand?  Undo is not part of the
picture.

> Clobbering a file doesn't imply that you lose its previous contents.

I never said otherwise.

Message #56 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Óscar Fuentes <ofv <at> wanadoo.es>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#23276: 25.0.92;
 Crash in auto-revert when file no longer present
Date: Sun, 17 Apr 2016 18:01:18 +0200

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

>> Clobbering a file doesn't imply that you lose its previous contents.
>
> I never said otherwise.

Then what's the meaning of your

>> > How is it different from clobbering a file by making it empty?

in response to John's

>> >> I would not want it to erase the buffer. Countless have been the
>> >> times that I've been working on a project, and an unbridled rm
>> >> took away code from the disk which I was very grateful to find was
>> >> still in a buffer.

?

Message #59 received at 23276 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Óscar Fuentes <ofv <at> wanadoo.es>
Cc: 23276 <at> debbugs.gnu.org
Subject: Re: bug#23276: 25.0.92;
 Crash in auto-revert when file no longer present
Date: Sun, 17 Apr 2016 19:10:22 +0300

> From: Óscar Fuentes <ofv <at> wanadoo.es>
> Date: Sun, 17 Apr 2016 18:01:18 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Clobbering a file doesn't imply that you lose its previous contents.
> >
> > I never said otherwise.
> 
> Then what's the meaning of your
> 
> >> > How is it different from clobbering a file by making it empty?
> 
> in response to John's
> 
> >> >> I would not want it to erase the buffer. Countless have been the
> >> >> times that I've been working on a project, and an unbridled rm
> >> >> took away code from the disk which I was very grateful to find was
> >> >> still in a buffer.
> 
> ?

Just what I said: a missing file is (in my eyes) very similar to a
zero-size file.

Message #64 received at 23276-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: John Wiegley <jwiegley <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 23276-done <at> debbugs.gnu.org, andlind <at> gmail.com
Subject: Re: bug#23276: 25.0.92;
 Crash in auto-revert when file no longer present
Date: Mon, 18 Apr 2016 10:24:25 +0200

John Wiegley <jwiegley <at> gmail.com> writes:

>> And I still am not convinced that deleting a file under auto-revert
>> shouldn't erase its buffer. Otherwise, it sounds like just half-auto-revert
>> to me. Would we keep the buffer non-empty if the file existed but was empty?
>
> I would not want it to erase the buffer. Countless have been the times that
> I've been working on a project, and an unbridled rm took away code from the
> disk which I was very grateful to find was still in a buffer.

I have committed the patch as shown recently (plus a comment) to the
emacs-25 branch. This is the least invasive change I could imagine, not
endangering the release. Closing the bug.

Further changes should go to master. I've prepared already a test case
for this. And while testing I found another annoyance: autorevert did
not restart once a deleted file has reappeared. This I have fixed also
in master.

The changes in master will be pushed once the emacs-25 branch has been
merged next time.

Best regards, Michael.

Message #67 received at 23276 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: John Mastro <john.b.mastro <at> gmail.com>
Cc: John Wiegley <jwiegley <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>,
 andlind <at> gmail.com, 23276 <at> debbugs.gnu.org
Subject: Re: bug#23276: 25.0.92;
 Crash in auto-revert when file no longer present
Date: Mon, 18 Apr 2016 10:26:07 +0200

John Mastro <john.b.mastro <at> gmail.com> writes:

> Speaking purely as a user, I think a case can be made that it really is
> different. We could say:
>
>     If the file exists, auto-revert updates the buffer based on its
>     (possibly empty) contents. If the file no longer exists, then there
>     is nothing for auto-revert to do, so it does not modify the buffer.

I have added this to the Commentary section of autorevert.el. Will be
pushed to the master branch next days.

Best regards, Michael.

Message #76 received at 23276 <at> debbugs.gnu.org (full text, mbox):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: 23276 <at> debbugs.gnu.org
Subject: autorevert for a deleted dired directory (ref: 23276)
Date: Tue, 29 Dec 2020 15:02:29 -0500

First, thanks to everyone/anyone who documented bug 23276 in the body of
file autorevert.el. Because of that in-line documentation, I was able to
easily find and read the relevant historical discussion.

I don't see in that long discussion treatment of the case of a dired
buffer when the directory it describes is deleted. In such a case, there
isn't any meaningful recovery operation that I can think of, and any
attempted operation on the buffer would only be a waste of time and
throw errors.

The biggest waste-of-time case that I can think of would be entering
wdired-mode on the buffer. I've tried it and it only throws an error on
exit, so a user could spend significant time editing the buffer for
naught. Of course, a solution for that specific case could be coded
outside of autorevert, to have wdired-mode itself refuse to operate on a
non-existent dired directory

  (unless (file-directory-p dired-directory)
    ...

which might be a good idea anyway, but it doesn't address all the other
less potentially time-consuming dired operations.

Personally, I wouldn't want to see the buffer deleted, because that
would mess up package diredc (shameless promo interruption: now on
MELPA!), but the buffer could be somehow prominently labeled as
describing a now-deleted directory, maybe in bold the top visible line.
That way a user would have a record of what was deleted, and would know
that the contents are only documentary and not operational. I've coded
handling in diredc for its history and navigation functions, but there
are also all the 'normal' dired operations to take into account by all
the normal dired users.

NOTE: Because I'm picking up on this thread from the web interface, I
don't have many of the email addresses that contributed to the thread,
so at this point I'm hoping the server will auto-magically copy anyone
who should be copied.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Message #79 received at 23276 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: 23276 <at> debbugs.gnu.org
Subject: Re: bug#23276: autorevert for a deleted dired directory (ref: 23276)
Date: Tue, 29 Dec 2020 22:13:13 +0200

> Date: Tue, 29 Dec 2020 15:02:29 -0500
> From: Boruch Baum <boruch_baum <at> gmx.com>
> 
> NOTE: Because I'm picking up on this thread from the web interface, I
> don't have many of the email addresses that contributed to the thread,

Why not?  The debbugs Web UI allows you to save any message in mbox
format, and then you can read into your favorite MUA and reply to the
message as if you received it.

Message #82 received at 23276 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Boruch Baum <boruch_baum <at> gmx.com>, 23276 <at> debbugs.gnu.org
Subject: RE: bug#23276: autorevert for a deleted dired directory (ref: 23276)
Date: Tue, 29 Dec 2020 12:24:19 -0800 (PST)

> I don't see in that long discussion treatment of the case of a dired
> buffer when the directory it describes is deleted. In such a case, there
> isn't any meaningful recovery operation that I can think of, and any
> attempted operation on the buffer would only be a waste of time and
> throw errors.
> 
> The biggest waste-of-time case that I can think of would be entering
> wdired-mode on the buffer. I've tried it and it only throws an error on
> exit, so a user could spend significant time editing the buffer for
> naught. Of course, a solution for that specific case could be coded
> outside of autorevert, to have wdired-mode itself refuse to operate on a
> non-existent dired directory
> 
>   (unless (file-directory-p dired-directory)
>     ...
> 
> which might be a good idea anyway, but it doesn't address all the other
> less potentially time-consuming dired operations.
> 
> Personally, I wouldn't want to see the buffer deleted, because that
> would mess up package diredc (shameless promo interruption: now on
> MELPA!), but the buffer could be somehow prominently labeled as
> describing a now-deleted directory, maybe in bold the top visible line.
> That way a user would have a record of what was deleted, and would know
> that the contents are only documentary and not operational. I've coded
> handling in diredc for its history and navigation functions, but there
> are also all the 'normal' dired operations to take into account by all
> the normal dired users.

My own take is different.  I think the behavior
should be similar to what we do for a file.

The only difference I can think of (so far) is that
the notion of "saving" the changes is combined with
the notion of turning off read-only.  For a file
those are two different things: `C-x C-q' doesn't
save editing changes to disk.

When you use `C-x C-q' to go back to Dired mode
from WDired, you are in effect saving your changes.

If you're in WDired making changes, and something -
ANYTHING, inside or outside Emacs - deletes the
directory, then what should happen is that when you
try `C-x C-q' to save your changes, the directory
and its files and subdirs are created, so that the
Dired buffer is made to correspond to the changes
you made.

That may not be easy to implement.  But ideally
that's the behavior I'd like: just like saving
changes to a file buffer, if something - ANYTHING -
deletes the file while you're editing its buffer.

Message #85 received at 23276 <at> debbugs.gnu.org (full text, mbox):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Anders Lindgren <andlind <at> gmail.com>,
 Michael Albinus <michael.albinus <at> gmx.de>,
 John Wiegley <jwiegley <at> gmail.com>, John Mastro <john.b.mastro <at> gmail.com>,
 Óscar Fuentes <ofv <at> wanadoo.es>
Cc: 23276 <at> debbugs.gnu.org
Subject: Re: bug#23276: autorevert for a deleted dired directory (ref: 23276)
Date: Tue, 29 Dec 2020 15:45:55 -0500

For everyone who didn't get the full supplemental bug report quoted in part
below:
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23276#76

On 2020-12-29 22:13, Eli Zaretskii wrote:
> > Date: Tue, 29 Dec 2020 15:02:29 -0500
> > From: Boruch Baum <boruch_baum <at> gmx.com>
> >
> > NOTE: Because I'm picking up on this thread from the web interface, I
> > don't have many of the email addresses that contributed to the thread,
>
> Why not?  The debbugs Web UI allows you to save any message in mbox
> format, and then you can read into your favorite MUA and reply to the
> message as if you received it.

So, I guess no auto-magic today? Thanks for the tip, but because each
contributor had their own message, it was still a manual process and
didn't end up saving any time, but hopefully now everyone can revisit
those glorious days of year 2016.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Message #88 received at 23276 <at> debbugs.gnu.org (full text, mbox):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 23276 <at> debbugs.gnu.org
Subject: Re: bug#23276: autorevert for a deleted dired directory (ref: 23276)
Date: Tue, 29 Dec 2020 16:18:20 -0500

On 2020-12-29 12:24, Drew Adams wrote:
> My own take is different. I think the behavior should be similar to
> what we do for a file.
>
> The only difference I can think of (so far) is that the notion of
> "saving" the changes is combined with the notion of turning off
> read-only. For a file those are two different things: `C-x C-q'
> doesn't save editing changes to disk.
>
> When you use `C-x C-q' to go back to Dired mode from WDired, you are
> in effect saving your changes.

I was familiar with the "C-c C-c" keybinding, but I tried your
keybinding just now for a simple edit and it work! I don't see it
documented like "C-c C-c" but both *are* bound to the same function.

>
> If you're in WDired making changes, and something - ANYTHING, inside
> or outside Emacs - deletes the directory, then what should happen is
> that when you try `C-x C-q' to save your changes, the directory and
> its files and subdirs are created, so that the Dired buffer is made to
> correspond to the changes you made.
>
> That may not be easy to implement. But ideally that's the behavior I'd
> like: just like saving changes to a file buffer, if something -
> ANYTHING - deletes the file while you're editing its buffer.

It would also create expectation-conflicts between inside-emacs
expectations and outside-emacs expectations. For example, if outside
emacs I perform a 'shred' operation on a dirtree, I wouldn't want that
operation undone by emacs. I would have a likewise expectation for a
simple delete in an environment that doesn't implement some form of
'trash-can'. At worst case, I'm imagining emacs performing file-locks on
all elements of huge dirtree in a multi-user environment, all for a
single file rename...

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Message #91 received at 23276 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: 23276 <at> debbugs.gnu.org
Subject: RE: bug#23276: autorevert for a deleted dired directory (ref: 23276)
Date: Tue, 29 Dec 2020 14:07:17 -0800 (PST)

> > When you use `C-x C-q' to go back to Dired mode from WDired, you are
> > in effect saving your changes.
> 
> I was familiar with the "C-c C-c" keybinding, but I tried your
> keybinding just now for a simple edit and it work! I don't see it
> documented like "C-c C-c" but both *are* bound to the same function.

And I in turn forgot about `C-c C-c' here.

Actually, `C-c C-c' is a bit better here
mentally, in terms of keeping to its typical
behavior of "finishing" some editing operation
and "sending" the finished result somewhere.

> > If you're in WDired making changes, and something - ANYTHING, inside
> > or outside Emacs - deletes the directory, then what should happen is
> > that when you try `C-x C-q' to save your changes, the directory and
> > its files and subdirs are created, so that the Dired buffer is made to
> > correspond to the changes you made.
> >
> > That may not be easy to implement. But ideally that's the behavior I'd
> > like: just like saving changes to a file buffer, if something -
> > ANYTHING - deletes the file while you're editing its buffer.
> 
> It would also create expectation-conflicts between inside-emacs
> expectations and outside-emacs expectations. For example, if outside
> emacs I perform a 'shred' operation on a dirtree, I wouldn't want that
> operation undone by emacs. I would have a likewise expectation for a
> simple delete in an environment that doesn't implement some form of
> 'trash-can'. At worst case, I'm imagining emacs performing file-locks on
> all elements of huge dirtree in a multi-user environment, all for a
> single file rename...

First, I don't expect what I'd prefer here to ever be
implemented.

Second, I don't see how the directory and its
contents case is essentially different from the
file and its contents case.

Of course they're different - a dir is more than
just a file.  But in the terms considered here, the
interactions with a user, and user expectations,
seem parallel, to me.

You can edit a file in Emacs, and something outside
Emacs can delete it from disk while you're editing
its buffer.  You _can_ (and thank goodness) still
save your edits to disk - the file is re-created.

OK, it's in fact a new file that's (typically)
created, with the same name.  And the same would
presumably happen for a directory.  But nothing
prevents an environment from using, say, the trash
or some cache to restore either file or dir, and
applying the edits implied by implicit diffs.

I'm really just saying that there would be some
(user) value in having the same or a similar UI
to how Emacs deals with file edits.  But for some
reason, when it comes to WDired, everyone seems
to suggest preliminary warnings, confirmation
demands or some such, to deal with what is pretty
much the same thing: editing and saving edits.

Message #94 received at 23276 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: 23276 <at> debbugs.gnu.org
Subject: Re: bug#23276: 25.0.92; Crash in auto-revert when file no longer
 present
Date: Wed, 27 Apr 2022 16:09:54 +0200

Boruch Baum <boruch_baum <at> gmx.com> writes:

> I don't see in that long discussion treatment of the case of a dired
> buffer when the directory it describes is deleted. In such a case, there
> isn't any meaningful recovery operation that I can think of, and any
> attempted operation on the buffer would only be a waste of time and
> throw errors.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I tried deleting a directory from underneath a Dired buffer (with
auto-revert on), and Emacs didn't do anything in particular with it
(which is consistent with how Emacs handles other files that disappear).

> The biggest waste-of-time case that I can think of would be entering
> wdired-mode on the buffer. I've tried it and it only throws an error on
> exit, so a user could spend significant time editing the buffer for
> naught. Of course, a solution for that specific case could be coded
> outside of autorevert, to have wdired-mode itself refuse to operate on a
> non-existent dired directory
> 
>   (unless (file-directory-p dired-directory)
>     ...

wdired (now, at least) warns about this situation, but I've now made it
signal an error in Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.