Al Viro wrote: > On Sat, Aug 20, 2011 at 12:37:56AM +0100, Jamie Lokier wrote: > > > Possible solution: > > > Then this can be solved, in principle (if there's no better way), by > > watching a "virtual directory" that gets all events for when the > > access doesn't have a parent directory. There needs to be some way to > > watch it, and some way to get the appropriate file from the event (as > > there is no real directory. Or maybe there could be a virtual > > filesystem (like /proc, /sys etc.) containing a magic directory that > > receives these inode-only events, such that lookups in that directory > > yield the affected file. Exactly as if the directory contains a hard > > link to every file, perhaps a text encoding of the handles passed > > through sys_open_by_handle_at. > > There is a better way - stop using idiotify... It has always been a > mistake, driven down our throats by filemangler and desktop crowd. Well you still have your sense of humour... I've never understood why you think it's about the file manager / desktop, or why you so strongly dislike the feature. It originated there historically, but that is not it's primary use. The implementation, sure, but you seem to dislike the very *principle* of subscribing to changes. Every interesting use of inotify that I've seen is for some kind of cache support, to eliminate the majority of stat() calls, to remove disk I/O (no stat means no inode), to ensure correctness (st_mtime is coarse and unreliable), and to avoid having to modify every application which might affect any file from which cached items are derived to explicitly notify all the applications which might use any of those files. You like high performance, reliable and correct behaviour, and high scalability. So I have never understood why you dislike the change-subscription principle so strongly, because it is a natural ally to those properties. All the best, -- Jamie -- 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
