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

Previous Next

Full log

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: <miha <at> kamnitnik.top>
Cc: 55578 <at> debbugs.gnu.org
Subject: Re: bug#55578: 29.0.50; auto-revert-use-notify vs 'git checkout --
 <file>'
Date: Tue, 24 May 2022 19:52:37 +0200

<miha <at> 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.

Previous Next

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