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

[Michael Albinus]

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

> Actually, it is (arguably) a bug. With two buffers referring to
> distinct hard links for the same file, surely we want a change in that
> file to trigger notification for both! (It's quite an exotic case, not
> the least because Emacs normally recognises hard links as if they were
> the same file name.)

By design, in filenotify.el, we want see only events which are related
to the file *name*. If you want to be notified for both buffers, you
need to watch both file (names).

(Well, re-reading the docstring and the manual for `file-notify-add-watch',
this isn't said explicitly. Likely, we shall precise this.)

> However, with the kqueue back-end, file-notify watches do trigger for
> both, as expected.

Hmm, this is inconsistent. Worth a buig report?

> The reason is that file-notify does not call inotify-add-watch on
> individual files, as in your example above, but on their containing
> directory ("/tmp" in your example). When monitoring a directory with
> two hard links to the same file, and the file is changed, inotify
> (sensibly) only reports a change to one of the links (the one employed
> for the change). Thus, the logic is in the Linux kernel, not in
> filenotify.
>
> For kqueue it is different: here, changes to files are not reported
> when a watch is monitoring their directory, so filenotify.el sets
> kqueue watches on each file instead. The same could be done with
> inotify (and w32notify, if I read the code right), but watching
> directories has certain advantages.

It was a design decision, that filenotify.el implements directory
watching. Since kqueue does not support this, it must be emulated, somehow.

>> One alternative approach could be to analyze the file system device
>> number, as returned by `file-attributes'. By this, we could detect
>> mounted file systems.
>
> Sort of; the interpretation is tricky, and as Eli commented, quite
> platform-specific.

I'm also not in favor of this approach, I just wanted to mention it.

>> But I don't believe that this information is always trustworty, given it
>> isn't used anywhere. And at least for remote files it doesn't tell you
>> anything. Furthermore, mounted file systems are not the only reason that
>> file notification doesn't work, and we need to poll.
>
> What other reasons are you thinking about?

The reasons you have already quoted somewhere else: sometimes, file
notification is not applicable; there are not enough descriptors left; a
file might have been deleted; a file notification process has been
killed silently; you name it ...

Best regards, Michael.