Re: File watch support in autorevert.el

[Michael Albinus]

Eli Zaretskii <address@hidden> writes:

>  . The code as written is too naive: it blindly assumes that every
>    single notification reported by the filesystem for a given watch is
>    necessarily the one requested in the auto-revert-notify-add-watch
>    call.  But that assumption is false, at least on Windows, where the
>    implementation actually watches events to the entire parent
>    directory of the file we are interested in.  So Emacs reverts the
>    file whenever _any_ file in the same directory was changed.  I
>    believe similar problems can happen with inotify, albeit much more
>    rarely.  For that reason, I think auto-revert-notify-handler should
>    filter events by ASPECTS/ACTION member, and on Windows also by FILE
>    member of the event.

Will do for the inotify case. It is a simple bit easier, because you can
install a file watch for exactly one file, and you can expect it returns
for that file only.

This will be different, when we implement `dired-buffer-stale-p' based
on file watches.

In general, something like IN_DELETE* and IN_MOVE* must be handled
properly. That's clearly missing in my first shot.

>  . It isn't clear to me that using IN_CLOSE_WRITE with inotify is TRT:
>    AFAIU, that would mean we only revert a file when the application
>    writing to it closes its descriptor.  IOW, if the application makes
>    several changes to the file during a prolonged operation, and
>    doesn't close and reopen the file in between, we will only see the
>    changes at the end, but not during the operation.  Wouldn't it be
>    better to use IN_MODIFY instead?

See my other message. I believe IN_CLOSE_WRITE is sufficient for the
inotify case, but I might be wrong. I would need a test case which shows
it.

>  . At least on Windows, turning on auto-revert-mode and then modifying
>    and saving the file announces that it was auto-reverted.  This
>    didn't happen with the auto-revert method that doesn't use file
>    notifications.  Is this a bug?

I have an old Emacs instance, w/o support of inotify in
autorevert.el. There I see the same message.

>  . I believe some of the features added to autorevert.el, such as a
>    hash list of watch descriptors, should be in some infrastructure
>    with appropriate APIs.

Yes. During these tests we want to identify these features. When
possible, I will try to add more general functions in autorevert.el,
which could be extracted later for a general API.

Best regards, Michael.