[lkml]   [2004]   [Jan]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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
> <>
> <>
> 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.


#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

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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:59    [W:0.090 / U:0.836 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site