Hi, On Thu, 2006-11-16 at 16:03 -0800, Prakash Sangappa wrote: > > How is file creation handled? It seems like you would need an event > > analogous to FILE_DELETE here to notice any newly added files. > > > The file creation will result in a FILE_MODIFIED event on the directory. So, > the application need to be watching the directory.
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. If my description is accurate, I don't think that approach is going to scale to large directories. A simple FILE_CREATE event would eliminate the need for this. > Also, a file could be linked under many directories. To be correct, > every time a file gets modified, all its parent directories that are > being watched will have to be notified. In order to do that, we will > need to have a file -> directories mapping, which is generally not > available. I know this is an implementation detail. The way inotify works in this case isn't ideal, but it works well enough. If you have /etc/foo.txt and /var/bar.txt which are hardlinks, if you watch /etc and touch /var/bar.txt, you don't get an event in /etc. (However, if you watch /etc/foo.txt and touch /var/bar.txt, you will get an event.) Hard links are sufficiently uncommon (at least among user data) that this corner case has produced exactly zero bug reports against Beagle, and probably against gnome-vfs as well. > This behavior aids proper multi threaded programing. The overhead > is just to re-register which will enable the file monitor. Note that > with the current approach events don't get queued up. The queuing > issues have been discussed before. Yeah, Robert Love mentioned that just about every file monitoring API other than inotify does this. As long as there is a files-changed-since-time-X API as well, it can probably be done in a non-racy way. Thanks, Joe _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
