Joe Shaw wrote:
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.
Yes. It is safer to do all this in the user space.
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.
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. 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. 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.
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.)
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.
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
-Prakash.
_______________________________________________
perf-discuss mailing list
[email protected]
