Mmm, the last commit was at 2008-10-20. So it does unfortunately look like using inotify would be for the best.
2009/6/3 Dan Kegel <[email protected]> > gamin is probably closer to usable, but I'm a bit nervous about > depending on it. It looks like the JDS guys found a performance bug > last year > http://mail.opensolaris.org/pipermail/jds-review/2008-March/002295.html > but no new release of gamin has appeared in > http://www.gnome.org/~veillard/gamin/sources/ > - Dan > > On Wed, Jun 3, 2009 at 11:03 AM, Stefan Nuxoll <[email protected]> > wrote: > > There is a rewrite (or cleaned up version, I'm not sure) maintained by > GNOME > > called gamin. > > > > 2009/6/3 Dan Kegel <[email protected]>: > >> FAM is pretty old, and didn't have a sterling reputation for > scalability. > >> inotify would probably be better. > >> (The FAM mailing list at SGI appears to be dead...?) > >> > >> On Wed, Jun 3, 2009 at 10:56 AM, Stefan Nuxoll <[email protected]> > >> wrote: > >>> Since we're using GTK for the Linux port would there be any reason not > >>> to use FAM (File Alteration Monitor) which supports things like this? > >>> Yet another dependency for users of other DE's, but most of them > >>> probably won't use chromium due to GTK anyway. > >>> > >>> 2009/6/3 Dan Kegel <[email protected]>: > >>>> Indeed. And because it's not recursive, you have to use inotify on > each > >>>> directory in the tree you're watching. Bleah. > >>>> > >>>> One example use is wine, which did have to define its own data > >>>> structure, I think: > >>>> http://source.winehq.org/git/wine.git/?a=history;f=server/change.c > >>>> > >>>> On Wed, Jun 3, 2009 at 10:16 AM, Stefan Nuxoll <[email protected]> > >>>> wrote: > >>>>> > >>>>> inotify is a piece of crap, you can only monitor a directory, from > >>>>> that you have to reread the listing and see what's changed for > >>>>> yourself. > >>>>> > >>>>> 2009/6/3 Paweł Hajdan Jr. <[email protected]>: > >>>>>> > >>>>>> Looks like it's not that simple. Nobody responded. :-/ > >>>>>> > >>>>>> I analyzed inotify-tools source and they do everything on paths. Of > >>>>>> course that means a lot of careful updating etc, but should work in > >>>>>> lack of more elegant solution. > >>>>>> > >>>>>> Paweł > >>>>>> > >>>>>> On Sun, May 24, 2009 at 20:47, [email protected] < > [email protected]> > >>>>>> wrote: > >>>>>>> I am trying to make a patch for recursive directory watcher on > linux > >>>>>>> using inotify event. > >>>>>>> > >>>>>>> When a new directory under watched directory is created, inotify > >>>>>>> event > >>>>>>> only gives me event->name relative to the watched directory. > >>>>>>> This makes it difficult to get the inode number of new directory > >>>>>>> because I am keeping track of watched inode numbers so far. > >>>>>>> > >>>>>>> I need to get "/xxx/yyy/newDirectory" from bare "newDirectory" that > >>>>>>> inotify event gives me so that I can get the inode number for > >>>>>>> newDirectory and then in turn update my watched inode structure. > >>>>>>> > >>>>>>> What would be a good way to get the absolute path of a new event > that > >>>>>>> inotify just reported without having to maintain my own data > >>>>>>> structure, i.e without having data structure that keeps watch > >>>>>>> descriptor and it's watched path? > >>>>>> > >>>>>> > > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Stefan Nuxoll <[email protected]> > >>>>> > >>>>> >>>> > >>>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> Stefan Nuxoll <[email protected]> > >>> > >> > > > > > > > > -- > > Stefan Nuxoll <[email protected]> > > > > > > > > > > > -- Stefan Nuxoll <[email protected]> --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
