Gail Nagle wrote:
> The file event discussed here in May 2006 is close to what I am looking for.
> Its only shortcoming is that a separate event is needed for each directory
> being tracked. A more useful interface would allow events to be received for
> all create/delete activity in a directory
The file event discussed here in May 2006 is close to what I am looking for.
Its only shortcoming is that a separate event is needed for each directory
being tracked. A more useful interface would allow events to be received for
all create/delete activity in a directory tree, starting from a giv
Hey Prakash,
2 comments see below:
prakash sangappa wrote:
PS> [snip]
PS>
PS> We have a good discussion going. To summarize...
PS>
PS>
PS> File event types
PS>
PS> FILE_ACCESS File was accessed
PS> FILE_MODIFIED File was modified.
PS> FILE_CREATE File/dire
[snip]
We have a good discussion going. To summarize...
File event types
FILE_ACCESS File was accessed
FILE_MODIFIED File was modified.
FILE_CREATE File/directory was created.
FILE_DELETE File/directory was deleted.
FILE_ATTRIB Fil
On Wed, 2006-05-10 at 23:28, prakash sangappa wrote:
Spotlight.
The distributed filesystem issue is somewhat addressed by remote
spotlight:
http://weblog.infoworld.com/enterprisemac/archives/2006/04/remote_desktop.html
"Remote Spotlight is a hugely useful feature. It launches Spotlight
searches
o
I found the following which talks about the file event notification
facility in Apples OS X 10.4. The fslogger is a utility which uses this
feature. Apparently this is the same feature used by 'Spotlight' too
http://www.kernelthread.com/software/fslogger
Their file events notification mechanism
On Fri, Prakash Sangappa wrote:
> Spencer Shepler wrote:
> >>It appears that the distributed filesystem implementation should
> >>provide necessary means
> >>to collect such events. I think the responsibility falls squarely on the
> >>distributed file system
> >>implementation. I don't of if th
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/m
Spencer Shepler wrote:
It appears that the distributed filesystem implementation should
provide necessary means
to collect such events. I think the responsibility falls squarely on the
distributed file system
implementation. I don't of if there are any distributed file system
implementation
On Fri, Prakash Sangappa wrote:
> Darren Kenny wrote:
> >Hi Prakash,
> >
> >I don't think it's the implementation that bridges between the kernel
> >and the user spaces that's important to JDS, and probably most other
> >people - it's the ultimate API that people will have to write to, and
> >I
Darren Kenny wrote:
Hi Prakash,
I don't think it's the implementation that bridges between the kernel
and the user spaces that's important to JDS, and probably most other
people - it's the ultimate API that people will have to write to, and
I think from this perspective that sysevents is not
Hi Prakash,
I don't think it's the implementation that bridges between the kernel
and the user spaces that's important to JDS, and probably most other
people - it's the ultimate API that people will have to write to, and I
think from this perspective that sysevents is not what we want - it may
Jonathan Adams wrote:
Ah, but you can just poll/select on the port fd to get notifications there
are events on it. So you're fine.
Great. (I'd heard a bit about event ports, but this is the first use of them
that's sounded useful to anything close to what I work on, so I've never learned
the
On Thu, May 04, 2006 at 05:53:51PM -0700, Alan Coopersmith wrote:
> Jonathan Adams wrote:
> >On Thu, May 04, 2006 at 05:47:06PM -0700, Alan Coopersmith wrote:
> >I believe the idea is more that you convert your pool/select loop into
> >a port_getn() on a single port, which all of your events are se
Jonathan Adams wrote:
On Thu, May 04, 2006 at 05:47:06PM -0700, Alan Coopersmith wrote:
I believe the idea is more that you convert your pool/select loop into
a port_getn() on a single port, which all of your events are set up on.
Not so easy to do when the poll/select loop is buried deep in th
On Thu, May 04, 2006 at 05:47:06PM -0700, Alan Coopersmith wrote:
> Prakash Sangappa wrote:
> >- Unlike the 'inotify' interfaces, which uses 'ioctls' to a device, our
> > interfaces will be based on the existing Event ports framework. The
> >events
> > will be delivered to a specified 'Event
Prakash Sangappa wrote:
- Unlike the 'inotify' interfaces, which uses 'ioctls' to a device, our
interfaces will be based on the existing Event ports framework. The
events
will be delivered to a specified 'Event port'(which is an fd).
Can this fd be polled via poll/select or will all co
Hi,
Prakash Sangappa wrote:
[snip lots of good discussion that I can't really add to]
FILE_CLOSE_WRITE - What is the purpose of this event? If it is
found to be useful, we could include it.
I would think it would be most useful for the indexing system for search
ie. only index a file that
Glynn Foster wrote:
Yeah, currently Beagle only indexes a relatively small amount of
per-user data, generally in $HOME - however, as has been mentioned,
it's probably one of the first proper use cases of inotify.
I'd suggest that it's definitely worth looking at what inotify does -
given th
Hey,
John Levon wrote:
On Thu, May 04, 2006 at 08:46:01AM -0700, Bart Smaalders wrote:
http://beaglewiki.org/Main_Page
as well as some other GNOME things, apparently.
This cannot scale.
It doesn't necessarily need to scale; from my understanding, Beagle is more
about watching ~/Documents/
On Thu, 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:0
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
John Levon wrote:
On Thu, May 04, 2006 at 08:46:01AM -0700, Bart Smaalders wrote:
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 get
On Thu, May 04, 2006 at 08:46:01AM -0700, Bart Smaalders wrote:
> >http://beaglewiki.org/Main_Page
> >
> >as well as some other GNOME things, apparently.
>
> This cannot scale.
It doesn't necessarily need to scale; from my understanding, Beagle is more
about watching ~/Documents/ than big lots o
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 ev
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 woul
John Levon wrote:
On Wed, May 03, 2006 at 02:44:01PM -0700, Prakash Sangappa wrote:
FILE_CREATE File/Directory was created.
I think GNOME and others want to be able to watch an entire directory tree. It
sounds like the proposal is that you can only watch a particular p
On Wed, May 03, 2006 at 02:44:01PM -0700, Prakash Sangappa wrote:
> FILE_CREATE File/Directory was created.
I think GNOME and others want to be able to watch an entire directory tree. It
sounds like the proposal is that you can only watch a particular path
"/etc/non_existent_file"
Hi All,
We are working on adding a 'file events notification/monitoring' mechanism
to the Event ports framework in Solaris.
There are several different implementations around this file events
notification mechanism currently available, like 'dnotify, inotify' for
Linux or the 'FAM' from SGI e
29 matches
Mail list logo
