As far as I know, Beagle is similar to Spotlight rather than the other
way round - it tries to copy Spotlight. It was very far behind Spotlight
when I last tried it.
A good article on file system events, indexing and search in Apple's
MacosX 10.4 Tiger is at:
http://arstechnica.com/reviews/os/macosx-10.4.ars/
(sections 6 to 12).
Eoin
On Thu, 2006-05-04 at 21:32, Michael Pogue wrote:
> See also Apple's Spotlight, which is similar to Linux's Beagle. I believe
> that
> Windows-Next will also have this capability. So, yes, I think this should be
> a
> primary use case for this new API.
>
> Mike
>
> John Levon wrote:
> > On Wed, May 03, 2006 at 07:31:08PM -0700, Prakash Sangappa wrote:
> >
> >
> >>If you where to watch for events on an entire directory tree, what types
> >>of events that would be?
> >
> >
> > Presumably there would be some way to specify, but file creation/deletion
> > would
> > be the most obviously useful events.
> >
> >
> >>How would this be useful?
> >
> >
> > Beagle wants it, I think:
> >
> > http://beaglewiki.org/Main_Page
> >
> > as well as some other GNOME things, apparently.
> >
> >
> >>can be to just a watch on the directory "/etc". The FILE_CREATE event
> >>would
> >>mean that a file or a directory was created under "/etc". Once the
> >>application gets this event, it can go and check if the file got created.
> >
> >
> > Does this mean we don't get told /what/ got created? Is an application that
> > wants to know "what files are disappearing/appearing under /foo/bar/?"
> > going to
> > have to readdir() the whole directory every time it gets an event?
> >
> >
> >>>How does it interact with unmounting the underlying filesystem?
> >>
> >>It will hold a reference to the 'vnode' of the file/directory in the kernel,
> >>while we have the file events monitor on it. If the file system gets
> >>unmounted, it will de-register the monitor and send an exception event
> >>saying
> >>the filesystem got unmounted. These exception events need to be defined.
> >
> >
> > Sounds sensible...
> >
> > regards
> > john
> > _______________________________________________
> > perf-discuss mailing list
> > perf-discuss@opensolaris.org
> _______________________________________________
> perf-discuss mailing list
> perf-discuss@opensolaris.org
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
