Re: File change notification

[jw schultz]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/