Re: [Emacs-diffs] trunk r115439: * autorevert.el (auto-revert-notify-add-watch): Do not handle symlinked files.

[Eli Zaretskii]

> From: Michael Albinus <address@hidden>
> Date: Tue, 10 Dec 2013 05:37:06 +0100
> Cc: address@hidden
> 
> Stefan Monnier <address@hidden> writes:
> 
> >> +  (when (or (string-match auto-revert-notify-exclude-dir-regexp
> >> +                    (expand-file-name default-directory))
> >> +      (not (file-symlink-p buffer-file-name)))
> >
> > I think this patch is acceptable, but if/when we try to write a generic
> > file-watcher Elisp API, it would be good to make this work (probably by
> > adding a watcher on the symlink's target).
> 
> That was my first idea, too. But when I tried to implement this, there
> were too much performance penalties, which would eat the advantages of
> file notifications.

Can you tell more about these performance problems?  Suppose we always
run the file name through file-truename, before submitting it to the
notification back-end -- what problems will this create?

> As far as I am aware, inotify could support symbolic links and their
> targets. For glib it seems to depend on the implementation. For kqueue
> (*BSD, Mac OS X; candidate as further basic library) I don't know how
> it is handled.

I'd prefer that we don't delegate such a delicate issue to the
back-end, the result is likely to be even more system dependencies
than what we have now.