Re: inotify-based file notifications missing sometimes

[Dima Kogan <lists@dima.secretsauce.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dima Kogan <lists@dima.secretsauce.net>
>> Date: Fri, 24 Oct 2014 23:17:57 -0700
>> 
>> Here I ask for notifications for two files, and print out the events as
>> they come in. While emacs is running this way, I modify those two files
>> using an external tool. I would expect to see modification events for
>> both of these files, but I only see them for one of the files.
>
> But you are not saying that having more than one file in the same
> directory under auto-revert-mode doesn't work for this reason, are
> you?  Because I just tried, and it does work, because autorevert.el
> does handle this situation.

I'm not saying that largely because this thread is explicitly not about
auto-revert-mode. autorevert.el likely handles this because it was
originally written to not use inotify at all (and is still that way for
remote files), and likely makes more thorough checks. I have not looked
into that at all. The patch in the other thread makes auto-revert-mode
event based, and is broken by the issue described in this thread.


>> Proposed solutions?
>
> I think it would help if you state explicitly what is the problem,
> that you want to be solved, and why.

The problem is that we provide utility functions in filenotify.el that
claim to do something and do not do it. More to the point of what I'm
doing, I want to fix the event-based auto-revert, as implemented in the
patch I sent to the list a few hours ago. The patch is fine, I think,
but the issue described HERE breaks it.


> Just to clarify: filenotify.el is infrastructure that currently
> (AFAIK) has only one user -- autorevert.el.  At the time the file
> notifications were introduced, there were many discussions about how
> best to design this infrastructure.  Eventually, the conclusion was
> that we should make these decisions as we go, as we add user-level
> features based on the notifications.  So for now, filenotify.el
> reflects the needs of its single user, and with that user it does its
> job.  If there are additional needs and goals not covered by that,
> they should be explicitly stated, and then filenotify.el might need to
> be extended/modified to cover them.

OK. That is reasonable. I have no problems with the filenotify.el API at
all, it's just that the API description is not being respected.

By the way, the other filenotify.el backend for linux (gfile) has an
issue as well. Running the same test with it DOES produce events for
both files, but events come throught only when the user touches emacs.
So when the files are modified, nothing shows up in *Messages*, but
pressing any key in the emacs window makes them pop up. I haven't looked
into the cause of that yet, but intend to shortly.

dima