On Thu, Mar 27, 2014 at 02:50:24PM +0100, Quentin Glidic wrote: > Hello, > > In GIO (GLib), the GFileMonitor[1] mechanism is using inotify for > local files. To detect file creation and some other weird cases, > they monitor the directory of the file and not the file directly > (see get_basename/get_dirname[2] usage). > > With sysfs, it does not work as expected for some reason. > > From a quick discussion of IRC with GLib folks, it appears that it > would be better fixed in sysfs directly. inotify does not and will not work on sysfs. Or procfs. Or devpts. Or any number of network filesystems. No matter how hard somebody might wish it to work, that's simply not feasible. Linus, what do you think about flat-out refusing to create the watches on filesystems that can't support them? At inotify_add_watch(2)/fanotify_mark(2) time. Do you think that it would break syscall ABI warranties? As it is, the caller has no way to tell it needs to go for a fallback, short of getting ENOSYS on inotify_init(). And it *does* need to have fallback, simply because there's no way in hell to get notifications for a lot of places in synthetic filesystems, etc. If userland developers pull that kind of stunts (see above re GLib crowd trying to defend their garbage by suggesting that kernel must somehow make *notify work on all filesystems), we'd better push back before that behaviour spreads. BTW, inotify(7) and inotify_add_watch(2) need to be fixed - they do not mention these limitations at all. Assuming that reader has a clue and realizes that there's no magic is not a good idea... -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
