Re: OSX FSEvents file watching support

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

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

> Btw, just between us: I'm much less enthusiastic today about file
> notifications than I was a few years ago.  Since this feature was
> introduced, we have learned about too many problematic cases that
> together spell out one simple truth: these facilities are not scalable
> enough.

Sadly, I must agree. One proof of this is, that even after years we have
no stable test case in filenotify-tests.el for arriving of mass events,
especially file-notify-test09-watched-file-in-watched-dir. Also other
test cases are flaky; I have adjusted them again and again over years.

Maybe we shall emphasize much more, what is written in the man page of
inotify:

--8<---------------cut here---------------start------------->8---
       With careful programming, an application can use inotify to efficiently
       monitor and cache the state of a set of filesystem  objects.   However,
       robust applications should allow for the fact that bugs in the monitor‐
       ing logic or races of the kind described  below  may  leave  the  cache
       inconsistent with the filesystem state.  It is probably wise to do some
       consistency checking, and rebuild the cache  when  inconsistencies  are
       detected.
--8<---------------cut here---------------end--------------->8---

> For me, the last straw was when I tried to watch a log file
> of building the Boost library in auto-revert-tail-mode -- this
> completely broke down because there were many events each second, both
> due to changes to the log itself and due to files being
> created/modified in the same directory.  Polling, OTOH, had no problem
> dealing with this situation.

We have already some defence mechanisms to handle such situations (I
believe). Maybe we shall implement better, in order to fall back to
polling automatically in case something unexpected happens.

However, this is nat basic file notification, but the upper level, auto
reverting using file notifications.

> I'm the last one to discourage someone from hacking Emacs, of course,
> but I don't consider adding yet another file notification back-end
> such a cool feature, given our somewhat disappointing experience.

OTOH, file notification is good if it acts over a limited set of file
changes. Whether recursive directory tracking belongs to it - I don't
know. But the proposed use case, lsp-mode, could fall into that category.

Best regards, Michael.