For many purposes you can avoid needing this functionality completely
with a little thought. For instance, say you're displaying files to
the user (like Finder does). In that case, a good technique is to
refresh your view every time the user activates your window. That
way, if they switch to another app and save something, you're
guaranteed to notice it at just the right time.
I think it'd be a rare case where that's a really useful solution,
to be honest.
Since kqueue doesn't work for networked filesystems (and,
importantly, since it cannot be made to work in the general case for
scaleability reasons), it's a very important solution actually.
It's entirely possible for the contents of a directory to be
changed by a background app. What happens if you're monitoring the
user's download directory while Safari's in the middle of a 35MB
download. This mechanism won't notice when the .download package
gets replaced by the actual retrieved file.
I suspect that Safari, being an Apple app, will be sending the
relevant NSWorkspace notifications, which (provided you're using the
same machine) will work just fine. But I can easily log-in to a
different machine and do such a download, in which case you won't get
a kqueue notification *or* an NSWorkspace notification.
Besides, this type of solution is only applicable to applications
that have visible UI displaying a directory listing (or similar
information). It's plainly not useful for a background application.
Uli pointed out that you can make one or two other improvements to
the technique, for instance, re-scanning a short time *after* the
window activates (to cope with the user selecting a file at the same
time as activating the window). You obviously also have the option
of checking periodically when the user is idle (which also works for
non-GUI apps).
