> Ok. It does seem correct that a IMON_CHANGED event gets sent for the parent
> directory, which was changed, and another IMON_DELETE event is sent for the
> child, which was deleted. This also seems to be the problem with the other
> two know bugs -- in each case imon was only generating an event for the
> parent directory, which isn't monitored, and the event gets ignored. I
> should do a little more testing to make sure I didn't break something else
> and then I'll put together an imon-0.0.2 patch for kernels 2.2 and 2.4.
Neat!
BUT...
As far as 2.4 kernels go, jrodman@xxxxxxxx mentioned that another mechanism
for directory notification has already gone in. I'm looking at 2.4.0-test9
now, and it looks like include/linux/dnotify.h provides a facility for being
notified by signals when the contents of a directory changes, a lot like
the patch from willy@thepuffingroup
(http://oss.sgi.com/projects/fam/archive/msg00091.html). (It's not there in
2.4.0-test1; I don't know which version it was introduced in.) On 2.4
kernels, fam should be able to use that; in fact, libfam could/should? do
the fcntl itself instead of contacting the fam daemon. (The problem there
is that it has to open the directory to do the fcntl, which means a client
which monitors a lot of directories can run out of file descriptors, and if
SIGPOLL/SIGIO is already being handled by the application, it won't like
libfam installing its own handler which re-scans the directory--or stats the
file, if that's what was being monitored--corresponding to the fd for which
the signal was sent.)
Anyway, an interesting thing to think about. Unless imon's hooks into the
filesystem code are rewritten, in 2.4 kernels I think fam will probably have
to live with the fcntl(directory, F_NOTIFY) mechanism.
--Rusty
--
Source code, list archive, and docs: http://oss.sgi.com/projects/fam/
To unsubscribe: echo unsubscribe fam | mail majordomo@xxxxxxxxxxx
|