[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: File watch support in autorevert.el
From: |
Eli Zaretskii |
Subject: |
Re: File watch support in autorevert.el |
Date: |
Fri, 11 Jan 2013 16:43:34 +0200 |
> 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?
- File watch support in autorevert.el, Michael Albinus, 2013/01/10
- Re: File watch support in autorevert.el, Stefan Monnier, 2013/01/10
- Re: File watch support in autorevert.el, Eli Zaretskii, 2013/01/11
- Re: File watch support in autorevert.el, Stefan Monnier, 2013/01/11
- Re: File watch support in autorevert.el, Michael Albinus, 2013/01/11
- Re: File watch support in autorevert.el, Eli Zaretskii, 2013/01/12
- Re: File watch support in autorevert.el, Michael Albinus, 2013/01/12
- Re: File watch support in autorevert.el, Eli Zaretskii, 2013/01/12