Hi, On Fri, 2006-11-17 at 14:13 -0800, Prakash Sangappa wrote: > > To make sure I am understanding correctly, let me step through an > > implementation that gnome-vfs would likely employ. Let's assume I have > > a view on a directory, and I want to watch for various changes to the > > files in the directory. > > > > To notice a new file I will need to (1) have a list of files contained > > within a directory stored ahead of time and (2) have a watch on the > > directory. > > > > When a file is created, it sends a FILE_MODIFIED event to me, but that > > only tells me that the directory itself has somehow been modified. I > > will have to walk the list of files in the directory, comparing them to > > the list I pre-stored to see if there is a new file in there. > > > > > Yes. It is safer to do all this in the user space.
I'm not sure what you mean by "safer," but it's definitely a lot harder to use and won't scale to large directories. Honestly I just think people won't use the API. > But then just having a FILE_CREATE event will not be enough. We will > require a FILE_DELETED event for each of the files getting deleted > from the directory. I thought this is what the FILE_DELETE event was for, but now I guess it is only sent when you are watching the files themselves. My answer to this is Yes! You do need a FILE_DELETE event on the directory as well. > Then we will have to queue events with file names, which means one > event for each file created, deleted. Then we will get into the > queuing issues. I think it's ok to drop events if the queue is overflowed. This is what inotify does and what (I believe) happens on Mac OS X as well. In reality it doesn't seem to happen very often. Inotify has the nice added feature that there is actually a special overflow event, so you can even detect when this happens and have a reasonable fallback. > Suppose we impose a limit on the number of events queued, then to > handle the overflow case where it would start missing events, the > application will need a fall back method which includes the above > steps you mentioned. True, but this is not the most common case. You're radically complicating the 95% use case for the 5% corner case for the consumers of your API. Maybe I am off-base here. My whole perspective on the file monitoring APIs come from a desktop developer background. There may be other use cases you have in mind that lean toward this implementation. I'd like to know what those are. > If multiple links of a file are being watched, then you will get a file > modified event with the current approach. > i.e from your example /etc/foo.txt and /var/bar.txt are hard links and > if /etc/foo.txt is watched and /var/bar.txt gets modified, then you get > the FILE_MODIFIED event on /etc/foo.txt. Yes, this is the same as inotify. My example of how inotify worked when watching directories was a counterexample to your assertion about the one-to-many relationship for hardlinked files to their parent directories. Joe _______________________________________________ perf-discuss mailing list [email protected]
