Re: File watch support in autorevert.el

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: Michael Albinus <address@hidden>,  address@hidden
> Date: Fri, 11 Jan 2013 09:34:33 -0500
> 
> >  . 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.

I agree.

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

I would suggest adding the 'size' filter as well, because Windows
doesn't update the last write time on every write to a file, only
after many writes.  (It does similar filtering with updating the
directory entry of the file, so 'size' alone will not do.)

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

You mean, with a timer?