bug#35418: [PATCH] Don't poll auto-revert files that use notification

[Michael Albinus <michael.albinus@gmx.de>]

Mattias Engdegård <mattiase@acm.org> writes:

>> Inotify didn't work on mounted directories. I don't know whether this
>> has improved.
>
> By 'work', do you mean receiving notification about changes made by
> the same machine or another machine? As far as I know, the NFS
> protocol has no means of propagating notifications, in contrast to
> SMB.

It fires notifications for changes made by the same machine:

--8<---------------cut here---------------start------------->8---
;; "/net/ford/albinus" is a mounted directory.
(write-region "foo" nil "/net/ford/albinus/tmp/foo")

(inotify-add-watch "/net/ford/albinus/tmp/foo"
		   t (lambda (event) (message "inotify %S" event)))
=> (3 . 0)

(write-region "foo" nil "/net/ford/albinus/tmp/foo")
=> inotify ((3 . 0) (modify) "/net/ford/albinus/tmp/foo" 0)
   inotify ((3 . 0) (open) "/net/ford/albinus/tmp/foo" 0)
   inotify ((3 . 0) (modify) "/net/ford/albinus/tmp/foo" 0)
   inotify ((3 . 0) (close-write) "/net/ford/albinus/tmp/foo" 0)
--8<---------------cut here---------------end--------------->8---

If I make a modification on the remote machine, nothing happens:

--8<---------------cut here---------------start------------->8---
;; Remote "/ssh:ford:/share/albinus" is the same as local "/net/ford/albinus".
(write-region "foo" nil "/ssh:ford:/share/albinus/tmp/foo")
--8<---------------cut here---------------end--------------->8---

>> What might be an alternative is to let the user decide. If we provide a
>> user option `auto-revert-dont-poll', a user could set it to t, and would
>> live with the consequences. If she tries to enable autorevert for a
>> mounted directory, which is not covered by file notifications, she might
>> be surprised.
>
> That is a possibility, although I'm generally not too fond of
> user-adjustable behaviour of this sort. If I understand you right, you
> propose that the default value should be 'always poll'?

The policy in Emacs is to set the default value to be compatible with
previous behavior. If time passes, and we see no drawback, the default
value could be changed. Usually, the next major E,acs version .

> I would prefer the default to be 'avoid polling' -- I doubt that
> malfunctions will be common or serious if they occur -- but I suppose
> it is better than the status quo.

Yes.

Best regards, Michael.