Re: File watch support in autorevert.el

[Michael Albinus]

Eli Zaretskii <address@hidden> writes:

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

I can speak only for the inotify case. According to my tests,
IN_CLOSE_WRITE will always happen once a file has been written on the
filesystem. See for example (commands have been applied in different shells):

--8<---------------cut here---------------start------------->8---
~$ echo xxx >>~/tmp/123

~$ inotifywait -mq ~/tmp/123
/home/albinmic/tmp/123 OPEN 
/home/albinmic/tmp/123 MODIFY 
/home/albinmic/tmp/123 CLOSE_WRITE,CLOSE 
--8<---------------cut here---------------end--------------->8---

Do you (Stefan?) have a use case where just IN_MODIFY has been fired,
w/o a corresponding IN_CLOSE_WRITE?

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

Hmm, as said already I have almost no chance to test it under Windows ...
I would let this implementation to somebody else.

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

The timer is still active. The file watch handler just marks buffers
where the related file has been changed. Revert happens when the timer
goes through the buffers markes via `auto-revert-active-p'. That sounds
like an acceptable compromise.

Best regards, Michael.