Re: filenotify.el

[Michael Albinus <michael.albinus@gmx.de>]

Davis Herring <herring@lanl.gov> writes:

> Why not just let the error from the underlying notification request
> appear?  (This is the usual bit about "don't call stat(2) before
> open(2); just deal with failures from the latter".)

That would be possible, yes. But I hope to improve
file-notify-supported-p, that it could also return a correct answer in
case the underlying library does not support the filesystem in question.

Example: mounted directories. (file-notify-supported-p "/mnt/dir") will
return t when either gfilenotify or inotify are linked to Emacs. And
file-notify-add-watch won't fail in either case.

But likely, in the inotify case you won't see events, because it does
not support mounted directories. In the gfilenotify case it shall work,
because glib's implementation uses polling, when other mechanisms fail.

file-notify-supported-p is not such clever yet. But users of
filenotify.el shall apply this function already, for the future when
file-notify-supported-p improves.

> Davis

Best regards, Michael.