unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: emacs-devel@gnu.org
Subject: Re: File watch support in autorevert.el
Date: Fri, 11 Jan 2013 17:57:52 +0200	[thread overview]
Message-ID: <83vcb3u2yn.fsf@gnu.org> (raw)
In-Reply-To: <87ip73n3xl.fsf@gmx.de>

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: emacs-devel@gnu.org
> Date: Fri, 11 Jan 2013 16:18:46 +0100
> 
> Eli Zaretskii <eliz@gnu.org> 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.

You cannot expect that, not in general, because there's no such
promise in the docs of these interfaces.  That's why the interface
returns to you the full information about the transaction.  I don't
think it's wise to ignore that information.

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

Since the documentation clearly says this event is generated when the
file is _closed_, I wonder why a test case is needed.

> >  . 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 don't see this in Emacs 24.2.92 on Windows.



  reply	other threads:[~2013-01-11 15:57 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-10 14:28 File watch support in autorevert.el Michael Albinus
2013-01-10 17:11 ` Stefan Monnier
2013-01-10 17:14   ` Lennart Borgman
2013-01-10 20:38   ` Michael Albinus
2013-01-11 10:05 ` Eli Zaretskii
2013-01-11 14:34   ` Stefan Monnier
2013-01-11 14:43     ` Eli Zaretskii
2013-01-11 15:01       ` Michael Albinus
2013-01-11 15:50         ` Eli Zaretskii
2013-01-11 16:09           ` Michael Albinus
2013-01-11 19:19             ` Eli Zaretskii
2013-01-11 16:19           ` Michael Albinus
2013-01-11 16:39         ` Stefan Monnier
2013-01-11 22:43           ` Michael Albinus
2013-01-12 11:28             ` Eli Zaretskii
2013-01-12 13:34               ` Michael Albinus
2013-01-12 15:09                 ` Eli Zaretskii
2013-01-12 19:08                   ` Michael Albinus
2013-01-17  9:38                   ` Michael Albinus
2013-01-17 16:54                     ` Eli Zaretskii
2013-01-17 19:19                       ` Michael Albinus
2013-01-17 19:39                         ` Eli Zaretskii
2013-01-11 15:57       ` Stefan Monnier
2013-01-11 15:18   ` Michael Albinus
2013-01-11 15:57     ` Eli Zaretskii [this message]
2013-01-11 16:31       ` Michael Albinus
2013-01-11 18:47         ` Eli Zaretskii
2013-01-11 16:44     ` Stefan Monnier
2013-01-11 22:47       ` Michael Albinus
2013-01-12 11:36         ` Eli Zaretskii
2013-01-12 13:14           ` Michael Albinus
2013-01-12 14:06             ` Eli Zaretskii
2013-01-12 14:16               ` Michael Albinus
2013-01-11 22:39   ` Michael Albinus
2013-01-11 23:01   ` Michael Albinus
2013-01-12 11:31     ` Eli Zaretskii
2013-01-12 13:08       ` Michael Albinus
2013-01-12 13:26         ` Michael Albinus
2013-01-12 14:03         ` Eli Zaretskii
2013-01-12 14:12           ` Michael Albinus
2013-01-12 14:39             ` Eli Zaretskii
2013-01-12 19:04               ` Michael Albinus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83vcb3u2yn.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=michael.albinus@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).