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"
28 matches
Mail list logo
