Re: File change notification

[R$B|d(Biger Klaehn<rudi _at_ xxxxxxxxxxxxxxxxxxx>]

jw schultz wrote:

[snip]

>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?
>
>  
>
Take a look at fs/read_write.c. There are calls to dnotify_parent in all 
file operation functions. There is a comment in fs/dnotify.c which says 
that dnotify_parent is "hopelessly wrong, but unfixable without API 
changes". Another good reason for a new file change notification api...

The only thing I am not so sure about is mmap. I think a mmapped file 
will not create change notifications.

>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.
>  
>
Whats wrong with that? You would just have to know the inode numbers of 
all directories in the subtree you are interested in. Then you can do a 
really fast inode->name translation using a hashtable or something. At 
least it is much more lightweight than having to open all directories :-)

I think that it is much cleaner and faster to report the inode numbers 
of the changed files since inode numbers are unique per filesystem and 
they are immediately available. The complicated mapping of inodes to 
path names should happen in user space only for the files the userspace 
process is interested in.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo _at_ vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/