bug#55578: 29.0.50; auto-revert-use-notify vs 'git checkout -- <file>'

bug#55578: 29.0.50; auto-revert-use-notify vs 'git checkout -- <file>'

[miha--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 3705 bytes --]

Visit a file in a clean git repository, modify it and save its buffer.
Turn on auto-revert-mode in its buffer.

Run 'git checkout -- <filename>' and notice that auto-revert-mode
doesn't revert the buffer immediately using 'notify', it only reverts it
according to auto-revert-interval.

This is in contrast to modifying the file with a command like
'echo test >> <filename>', after which auto-revert-mode reverts the
buffer instantly using 'notify'.

This seems to be because prior to writing the file, 'git checkout'
unlinks it first. It would be nice if auto-revert-mode worked with
notify in such cases as well.

git version 2.36.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh

In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, cairo version 1.17.6)
 of 2022-04-20 built on miha-pc
Repository revision: 4714f34928c12cc9ebda7c115526db4aa87c0d51
Repository branch: tmp
Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
System Description: Artix Linux

Configured using:
 'configure --without-libsystemd --with-native-compilation'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
WEBP X11 XDBE XIM XPM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.utf8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media rmc puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util text-property-search time-date seq gv
subr-x byte-opt bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice
simple 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 composite
emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help
abbrev obarray oclosure cl-preloaded button loaddefs faces cus-face
macroexp files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo move-toolbar gtk x-toolkit x multi-tty
make-network-process native-compile emacs)

Memory information:
((conses 16 59212 9167)
 (symbols 48 5734 0)
 (strings 32 16445 1783)
 (string-bytes 1 547865)
 (vectors 16 11787)
 (vector-slots 8 271542 16531)
 (floats 8 21 25)
 (intervals 56 334 7)
 (buffers 992 11))


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

bug#55578: 29.0.50; auto-revert-use-notify vs 'git checkout -- <file>'

[Michael Albinus]

miha--- via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

Hi,

> Visit a file in a clean git repository, modify it and save its buffer.
> Turn on auto-revert-mode in its buffer.
>
> Run 'git checkout -- <filename>' and notice that auto-revert-mode
> doesn't revert the buffer immediately using 'notify', it only reverts it
> according to auto-revert-interval.
>
> This is in contrast to modifying the file with a command like
> 'echo test >> <filename>', after which auto-revert-mode reverts the
> buffer instantly using 'notify'.
>
> This seems to be because prior to writing the file, 'git checkout'
> unlinks it first. It would be nice if auto-revert-mode worked with
> notify in such cases as well.

Indeed, git deletes and (re-)creates the file. See the following file
notify events, when monitoring the git repository (/tmp/xxx is the repo,
/tmp/xxx/foo the file). This happens, after calling "git checkout -- foo":

--8<---------------cut here---------------start------------->8---
file-notify-handle-event (file-notify ((1 . 0) (delete) "foo" 0) file-notify--callback-inotify)
file-notify-handle-event (file-notify ((1 . 0) (create) "foo" 0) file-notify--callback-inotify)
file-notify-handle-event (file-notify ((1 . 0) (modify) "foo" 0) file-notify--callback-inotify)
--8<---------------cut here---------------end--------------->8---

The corresponding events for the file /tmp/xxx/foo are

--8<---------------cut here---------------start------------->8---
file-notify-handle-event (file-notify ((1 . 1) (delete) "foo" 0) file-notify--callback-inotify)
file-notify-callback (1 . 1) deleted "/tmp/xxx/foo" nil #s(file-notify--watch "/tmp/xxx" "foo" auto-revert-notify-handler) "/tmp/xxx/foo" "/tmp/xxx"
auto-revert-notify-handler ((1 . 1) deleted "/tmp/xxx/foo")
file-notify-handle-event (file-notify ((1 . 1) stopped "/tmp/xxx/foo") auto-revert-notify-handler)
auto-revert-notify-handler ((1 . 1) stopped "/tmp/xxx/foo")
--8<---------------cut here---------------end--------------->8---

As you can see, file notifications are stopped after receiving the
'delete' event. This is a feature of our file notifications implementation.

Running "echo test >> foo" instead shows the events

--8<---------------cut here---------------start------------->8---
file-notify-handle-event (file-notify ((1 . 0) (modify) "foo" 0) file-notify--callback-inotify)
file-notify-callback (1 . 0) changed "/tmp/xxx/foo" nil #s(file-notify--watch "/tmp/xxx" nil auto-revert-notify-handler) "/tmp/xxx" "/tmp/xxx"
auto-revert-notify-handler ((1 . 0) changed "/tmp/xxx/foo")
--8<---------------cut here---------------end--------------->8---

This works as expected. So I fear there's nothing we can do.

Best regards, Michael.

bug#55578: 29.0.50; auto-revert-use-notify vs 'git checkout -- <file>'

[miha--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 2561 bytes --]

Michael Albinus <michael.albinus@gmx.de> writes:

> Indeed, git deletes and (re-)creates the file. See the following file
> notify events, when monitoring the git repository (/tmp/xxx is the repo,
> /tmp/xxx/foo the file). This happens, after calling "git checkout -- foo":
>
> --8<---------------cut here---------------start------------->8---
> file-notify-handle-event (file-notify ((1 . 0) (delete) "foo" 0) file-notify--callback-inotify)
> file-notify-handle-event (file-notify ((1 . 0) (create) "foo" 0) file-notify--callback-inotify)
> file-notify-handle-event (file-notify ((1 . 0) (modify) "foo" 0) file-notify--callback-inotify)
> --8<---------------cut here---------------end--------------->8---
>
> The corresponding events for the file /tmp/xxx/foo are
>
> --8<---------------cut here---------------start------------->8---
> file-notify-handle-event (file-notify ((1 . 1) (delete) "foo" 0) file-notify--callback-inotify)
> file-notify-callback (1 . 1) deleted "/tmp/xxx/foo" nil #s(file-notify--watch "/tmp/xxx" "foo" auto-revert-notify-handler) "/tmp/xxx/foo" "/tmp/xxx"
> auto-revert-notify-handler ((1 . 1) deleted "/tmp/xxx/foo")
> file-notify-handle-event (file-notify ((1 . 1) stopped "/tmp/xxx/foo") auto-revert-notify-handler)
> auto-revert-notify-handler ((1 . 1) stopped "/tmp/xxx/foo")
> --8<---------------cut here---------------end--------------->8---
>
> As you can see, file notifications are stopped after receiving the
> 'delete' event. This is a feature of our file notifications implementation.
>
> Running "echo test >> foo" instead shows the events
>
> --8<---------------cut here---------------start------------->8---
> file-notify-handle-event (file-notify ((1 . 0) (modify) "foo" 0) file-notify--callback-inotify)
> file-notify-callback (1 . 0) changed "/tmp/xxx/foo" nil #s(file-notify--watch "/tmp/xxx" nil auto-revert-notify-handler) "/tmp/xxx" "/tmp/xxx"
> auto-revert-notify-handler ((1 . 0) changed "/tmp/xxx/foo")
> --8<---------------cut here---------------end--------------->8---
>
> This works as expected. So I fear there's nothing we can do.

I imagine that after receiving a 'delete' event, auto-revert-mode could
set up a file-notify watch handler on the directory containing the (now
deleted) file. This handler would respond to a 'create' event
corresponding to the filename by reverting the buffer, removing the
directory file-notify watch and (re-)adding an ordinary file-notify
handler on the file.

Are there any obvious flaws with this approach that I'm missing?

> Best regards, Michael.

Best regards.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

bug#55578: 29.0.50; auto-revert-use-notify vs 'git checkout -- <file>'

[Michael Albinus]

<miha@kamnitnik.top> writes:

Hi,

> I imagine that after receiving a 'delete' event, auto-revert-mode could
> set up a file-notify watch handler on the directory containing the (now
> deleted) file. This handler would respond to a 'create' event
> corresponding to the filename by reverting the buffer, removing the
> directory file-notify watch and (re-)adding an ordinary file-notify
> handler on the file.

Anything goes. But there are traps.

> Are there any obvious flaws with this approach that I'm missing?

See the notifications the auto-revert handler receives:

--8<---------------cut here---------------start------------->8---
file-notify-handle-event (file-notify ((1 . 1) (delete) "foo" 0) file-notify--callback-inotify)
file-notify-callback (1 . 1) deleted "/tmp/xxx/foo" nil #s(file-notify--watch "/tmp/xxx" "foo" auto-revert-notify-handler) "/tmp/xxx/foo" "/tmp/xxx"
auto-revert-notify-handler ((1 . 1) deleted "/tmp/xxx/foo")
file-notify-handle-event (file-notify ((1 . 1) stopped "/tmp/xxx/foo") auto-revert-notify-handler)
auto-revert-notify-handler ((1 . 1) stopped "/tmp/xxx/foo")
--8<---------------cut here---------------end--------------->8---

The relevant event `auto-revert-notify-handler' reacts on is the
`stopped' event. In this case it deletes the file monitor, and continues
with polling. The `delete' event, received before, is ignored.

Receiving the `stopped' event can have different reasons. It happens
when the monitored file is deleted (like in our case). It could also
happen when the user has killed the corresponding file monitor, either
explicitly (calling `file-notify-rm-{all-watches,watch}'), or implicitly
by calling something else. The autorevert package cannot know the
reason, and it cannot know, whether the file is deleted and will be
recreated, possibly. So we cannot implement an automatism as above.

What we could implement is a mechanism, which checks while polling,
whether file notifications could be instantiated instead. This does not
need to be restricted to the case, that the file was deleted and then
created, again. It could be activated for any auto-revert polling
activitiy, and it must be an opt-in to be configured by the user. Or at
least restricted to use cases where it would make sense, like monitoring
a git repository. For example a minor mode `auto-revert-restart-notify-mode'.

> Best regards.

Best regards, Michael.

bug#55578: 29.0.50; auto-revert-use-notify vs 'git checkout -- <file>'

[Michael Albinus]

Michael Albinus <michael.albinus@gmx.de> writes:

Hi,

> What we could implement is a mechanism, which checks while polling,
> whether file notifications could be instantiated instead. This does not
> need to be restricted to the case, that the file was deleted and then
> created, again. It could be activated for any auto-revert polling
> activitiy, and it must be an opt-in to be configured by the user. Or at
> least restricted to use cases where it would make sense, like monitoring
> a git repository. For example a minor mode `auto-revert-restart-notify-mode'.

Oops, I've just retested. Looks like we have already this. While
polling, auto-revert-buffer checks already whether it could
(re-)activate file notification for that file.

So there's nothing left to do, right?

Best regards, Michael.

bug#55578: 29.0.50; auto-revert-use-notify vs 'git checkout -- <file>'

[Michael Albinus]

Michael Albinus <michael.albinus@gmx.de> writes:

Hi,

>> What we could implement is a mechanism, which checks while polling,
>> whether file notifications could be instantiated instead. This does not
>> need to be restricted to the case, that the file was deleted and then
>> created, again. It could be activated for any auto-revert polling
>> activitiy, and it must be an opt-in to be configured by the user. Or at
>> least restricted to use cases where it would make sense, like monitoring
>> a git repository. For example a minor mode `auto-revert-restart-notify-mode'.
>
> Oops, I've just retested. Looks like we have already this. While
> polling, auto-revert-buffer checks already whether it could
> (re-)activate file notification for that file.
>
> So there's nothing left to do, right?

No response for weeks, so I assume it's OK. I'm closing the bug. Feel
free to reply if you believe there're still problems.

Best regards, Michael.