Well, I don't know much about file systems, but isn't it always better to be notified than to poll ? First, having a notification system
means it's instantaneous. Second, I'd imagine querying the state of a file has a cost (especially if it can't be cached and needs a real access to the hard drive). Third, it'd avoid a waste of CPU resources
(which may be important for power consumption, since, from what I understood, the more a program has fixed timers, the more it wakes the CPU from sleep). Fourth, being notified is more high-level, since the notification itself can be implemented by polling. One could imagine a
notification API where the backend would use inotify if available, polling if not.
> But it could also be a pain in the neck to have these changes occur > while you're moving around in the Dired buffer and making changes.
Agreed. Maybe couple it with a condition like "the user hasn't done anything to the buffer for n seconds" ?
I also agree that notification for files shouldn't be turned on by default. When dealing with files that are modified in more than one
place at the same time, the simpler and safer the default is, the better. It would be interesting to provide the feature for advanced users though (ie users who know what they want). In any case, an inotify API could be a nice basis for customisation/other modes (kinda like the dbus interface)