lkml.org 
[lkml]   [2004]   [Jan]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: File change notification
    On Wed, Dec 31, 2003 at 05:42:45PM +0100, Rüdiger Klaehn wrote:
    > Hi everybody.
    >
    > This is my first post to lkml, so please be patient with me
    >
    > I have been wondering for some time why there is no decent file change
    > notification mechanism in linux. Is there some deep philosophical reason
    > for this, or is it just that nobody has found the time to implement it?
    > If it is the latter, I am willing to implement it as long there is a
    > chance to get this accepted into the mainstream kernel.
    >
    > Is there already somebody working on this problem? I know a few efforts
    > that try to do something similar, but they all work by intercepting
    > every single system call that has to do with files, and they are thus
    > not very fast. See for example
    > <http://www.bangstate.com/software.html#changedfiles>
    > <http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/openxdsm/openxdsm/eventmodule/>
    >
    >
    > The dnotify mechanism is very limited since it requires a file handle,
    > it is not working for whole directory trees and it does not report much
    > useful information. For example to watch for changes in the /home tree
    > you would have to open every single directory in the tree, which would
    > probably not even work since it would require more than the maximum
    > number of file handles. If you have a directory with many files in it,
    > the only thing dnotify tells you is that something has changed in the
    > directory, so you have to rescan the whole directory to find out which
    > file has changed. Kind of defeats the purpose of change notification...
    >
    > What I would like to have would be some way to watch for certain changes
    > anywhere in a whole tree or even the whole file system. This new
    > mechanism should have no measurable performance impact and should log
    > all information that is readily available. The amount of new code in
    > kernel space should be as small as possible. So complicated stuff like
    > pattern matching would have to happen in user space.
    >
    > I wrote some experimental mechanism yesterday. Whenever a file is
    > accessed or changed, I write all easily available information to a ring
    > buffer which is presented to user space as a device. The information
    > that is easily available is the inode number of the file or directory
    > that has changed, the inode number of the directory in which the change
    > took place, and in most cases the name of the dentry of the file that
    > has changed.

    hmm...


    #ln tree1/sub/dir/file tree2/sub/dir/file
    #watch_tree tree1 &
    #do_something_to tree2/sub/dir/file

    A dnotify can potentially know about open, chown, chmod,
    utimes and possibly link of the files by watching the paths
    and cwd; meaning it won't know about alternate paths. How
    is it to know about read, write, fchown, fchmod and
    truncate?

    Perhaps someone else has a more fertile imagination but
    short of looking up all the file inode numbers of the tree
    in question and watching that whole list this sounds futile.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:59    [W:0.024 / U:1.244 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site