> The kernel should send a signal to a process (that has registered for
> it) to inform it that something has changed in its `pwd`. This way,
> file managers won't have to poll for directory updates, they can say
> 'signal me if something changes here', and sleep.
> The ftpd could then register itself for that, and raise a 'haven't
> told this connect yet' flag per active connection, when a directory
> changes. Another command could be added to ftp then... sending it
> would check that bit, and say either, yes, the dir has been updated at
> this end, or no, it's the same as when you logged on. After reading
> that status, the bit would reset; you don't have to read the dir
> listing to reset it. If you made the change yourself, you track it
> maybe, like 'efs' does.
> I think it would work well for nfs connected filesystems too.
NFS is a stateless (cough cough) protocol. The server has no idea that
a client is in a directory and no way to determine this information.
this could leave the client machine with polling. Or you can simply
take the lockd path and write a separate rpc service on the server with
which you can register.
For ftp, most servers time out after a couple minutes of inactivity. It
only looks seemless because you are using efs which will reopen the
connection. I don't think people really want to support ftp sessions
which stay open forever sending directory update information back and
forth. If you need something like this often, it suggests you want a
real file-system. NFS is a poor excuse for one, but you could mount
the tree with tcp-nfs, and get on with your work.
And yes, you could probably easily add something which sends a SIGDIRCH
when the inode count goes up on a directory (or one of its immediate
children) to a process with that directory as cwd. A default action of
SIG_IGN is obvious. However, it's a bit useless for an example of emacs
with multiple dired buffers, or a generic file manager handling two
trees. It couldn't watch both at the same time. So to get around that,
it'd have to fork off a child for each directory it wanted to watch,
have them sit there, and talk to them via some form of IPC.
Now let's say you expand the proposal to include presenting a list of
directories to watch, you still have problems with NFS and ftp. And
then you'll ned some mechanism to tell which directory changed, or
you'll just have to scan them all.
If you are serious about such a system, my suggestion would be to
prototype up a generic service that people can register with to be
notified when a directory changes. Don't bother putting it in the
kernel, just have it poll every so often. Then once you have proof of
concept and a well-defined generic API, get it spread around. And then
you can tell people, "and look we can even get some kernel performance
leverage on some systems, but it's not a requirement."
If you limit followups to not include xemacs-beta-discuss, please CC me.
-- David Moore <dmoore@ucsd.edu> | Computer Systems Lab __o UCSD Dept. Computer Science - 0114 | Work: (619) 534-8604 _ \<,_ La Jolla, CA 92093-0114 | Fax: (619) 534-1445 (_)/ (_) <URL:http://oj.egbt.org/dmoore/> | In a cloud bones of steel.