Messages in this thread |  | | | Date | Thu, 1 Jan 2004 02:47:17 -0800 | | From | jw schultz <> | | Subject | Re: 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/
|  |