Re: VFS event hooks

Dale Amon (amon@vnl.com)
Sat, 26 Jun 1999 20:34:05 +0100 (BST)


On Sat, 26 Jun 1999, Linus Torvalds wrote:
> Note that the poll() approach would simply mean that the file browser
> would have each directory that it displays open - and running poll on
> them. Whenever poll indicates that the directory changed, it re-reads the
> directory and updates as necessary.
>

In a NeXT style browser that might not be too bad. You would need one
open directory for each heirarchy level from left to right (If you
are familair with the NeXT browser).

A desktop app would have to keep a poll on every icon represented file
on the desktop. However, if the browser or desktop have an fd, the
file won't actually delete until the app closes it's fd. So does the
poll tell you that a delete is pending? Does it treat a delete on a file
with hardlinks the same as one that does not? Would I be right in
guessing that it is up to the userland prog to stat and figure all this
out?

> One argument I have heard and partially buy into is that this doesn't work
> over networked files, but it actually _does_ work fairly well: the kernel
> has to have the logic to check up-to-datedness anyway, so that could be
> extended fairly easily (but yes, networked filesystems would probably have
> a minute or two before they noticed remote updates).
>

NFS can be pretty slow in any case, so why would I expect poll() to
be better than the underlying fs? :-)

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