Re: File watch support in autorevert.el

[Stefan Monnier]

>  . 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.

That seems like a good candidate for something the common API could
hide/provide, I think.

>  . 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?

For auto-revert-tail-mode, IN_CLOSE_WRITE is definitely insufficient
since the common use case is when we watch a log file, so the CLOSE may
never happen.

The non-inotify code does something akin to the IN_MODIFY, indeed.
But at the same time, it's often preferable to wait a bit longer for the
application to finish writing the new version of the file.  I think the
perfect behavior lies somewhere in-between: when we get an
IN_CLOSE_WRITE, we should revert immediately, but when we get an
IN_MODIFY we should revert "soon".


        Stefan