lkml.org 
[lkml]   [2011]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: PROBLEM: 2.6.35.7 to 3.0 Inotify events missing
    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


    \
     
     \ /
      Last update: 2011-08-20 05:09    [W:2.839 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site