On Wed, 3 Oct 2001, Rusty Ballinger wrote:
> > If several changes are made to one file in the same second, fam will only
> > report the first one.
>
> Even when you're using imon, the idea isn't that you get one event per
> file operation. (imon has code which intentionally notifies the client
> only once when multiple operations of the same type happen in rapid
> succession on the same file.)
I know that. But one last event must be sent after the final modification,
or clients will "hang" showing an "invalid" state.
This happened for us in Nautilus. When saving a file fam sent an event for
the truncate, leading to Nautilus updating it's data, showing a file size
of zero. Then when the changes that wrote to the file arrived they weren't
detected as changes by fam, because they were in the same second. This
caused Nautilus to keep displaying 0 bytes for the file.
> The question of whether Interest::do_stat() should return true when some of
> the other stat bits have changed is a good one. Since (in most cases) the
> polling code is just a fallback for when the kernel won't provide
> notification, and (I think) imon sends events on uid/gid/mode changes, I
> think that part of your patch is right.
I don't understand this comment. This has very little to do with polling
mode. The code path for an imon CHANGED event always goes through
Interest::do_stat(), so if this function returns false (as in the case of
the seconds race) that imon event is ignored. Just like the case in the
dnotigfy case.
/ Alex
--
Source code, list archive, and docs: http://oss.sgi.com/projects/fam/
To unsubscribe: echo unsubscribe fam | mail majordomo@xxxxxxxxxxx
|