Here's a transcript after an ideastorm on irc this morning. i just did a quick look through the code. it seems to me filehandles are a tough issue to sidetrack. if nepomuk used some extra diskspace to hold only one file with the entire contents of the currently indexable directories. filewatch could instead watch only that handle for updates and parse on gamin emits to find out what recently changes. kind of like a metadata journal but called say nepomuk ledger. the same idea anyway. fsync would be a bitch more than probably on a notebook, however most of it can be seen in ram. compcache with the equivalent of a full '# find / .' and filehandle pageswap after pageswap. it's great to have handles open after a find command because the reuse is killer, but not all apps (ie amarok) pick up on why. i don't think amarok uses kio. e.g. fileledger service: hash of file, current path, file name, optional filesize. 4 columbs.(sic) so the ledger service picks up on a new notify on fileledger.xml or what have you, and spits the latest entr(ies) having been moved or modified to nepomuk-core. Database ends up updated in-DB. I think tail does moderately well as far as memory / filewatch usage, so it should be an easy way around the issue. -I may have a QT oversight, I'm not certain but the main glib loop supposedly in qt should help matters as far as filewatch events actually being triggered by an automatic parse on inotify.-
practical experience, with a full file open by a service who would bother saving :) A bitch. (Freud-Daemon would be the closest the kernel would go IMO...a daemon. Again.) unpremeditated (tail -f ) practical terminology, a follow. write-then-read, not C-O-W. off-topic: I wonder if Quassel has a direct-to-printer option? hmm, brainstorm. how does kio handle inotify events and can they actually emit a signal? e.g. a file was moved. i'm thinking if the desktop actually was separated via kio (ie gated to not actually bother with files not being interacted with on the desktop shell) it should be easier to separate systems. i'm reminded of a plane that hit a swamp which they blamed on a shipper piling boxes in a doorway. it's termed a system accident or a cascade failure or something similar. anyway, isolating systems; if kio was to trigger an inotify event on move and increment the ledger, nepomuk was to pick up the notification via filewatch on ledger.xml and do a quick parse on the last few entries the systems should be isolated enough to actually grep a feel for what they would be doing in tandem at any one time. nepomuk updates aren't necessarily needed to be instantaneous. if kio can be rigged, we can call it a morning and blame it all on fuse for not being 'there'. On 5/1/10, [email protected] <[email protected]> wrote: > Send Nepomuk mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.kde.org/mailman/listinfo/nepomuk > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Nepomuk digest..." > > > Today's Topics: > > 1. Re: Bugs, Patches and Scripts. - StrigiService & KInotify > (Vishesh Handa) > 2. Re: Bugs, Patches and Scripts. - StrigiService & KInotify > (Carlos Ruiz) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 30 Apr 2010 17:37:03 +0530 > From: Vishesh Handa <[email protected]> > Subject: Re: [Nepomuk] Bugs, Patches and Scripts. - StrigiService & > KInotify > To: Sebastian Tr?g <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > *This patch doesn't work perfectly.* > > I seem to to be duplicating code from StrigiServiceConfig, which is not > something I'm too happy about. > > The moment some watched folder is moved/renamed, metadata mover fires up, > and starts moving the metadata. Meanwhile the strigi config file is updated > and the strigi service detects that the file has been changed (exact same > code as in the testpatch) and then proceeds to delete unnecessary metadata > via removeOldAndUnwantedEntries(). Which removes some of the indexed data. > And since some of the metadata has been removed the filewatch service can't > move it. After that the strigi service proceeds to index the moved files > who's metadata isn't intact. > > :-/ > > It's doing what we want, but not how we want it. We need to delay writing to > the config file until the metadata mover has finished is job. I could just > slap on a signal which is fired when it changes from a Busy to Idle state > (and that'll work) but for all you know the user could be performing other > tasks and the metadata mover doesn't become idle for a long time. (Maybe > he's monitoring a network drive where other users are doing stuff). > This method will ultimately result in what we want except when then this > happens - > 1. The user moves some folder which is being indexed. > 2. The metadata mover is active. > 3. He edits the files being watched via kcm. > 4. The metadata mover becomes idle. > > There is one more issue. Say I have an indexed folder *Boo*, and it has a > sub-folder *Yoda*. Yoda is moved somewhere outside Boo which isn't being > indexed. Should Yoda still be indexed? Or Not? I think it should be. What do > you think? > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://mail.kde.org/pipermail/nepomuk/attachments/20100430/9d80a1d1/attachment-0001.htm > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: patch.diff > Type: text/x-patch > Size: 3198 bytes > Desc: not available > Url : > http://mail.kde.org/pipermail/nepomuk/attachments/20100430/9d80a1d1/attachment-0001.diff > > ------------------------------ > > Message: 2 > Date: Fri, 30 Apr 2010 12:44:03 +0000 > From: "Carlos Ruiz" <[email protected]> > Subject: Re: [Nepomuk] Bugs, Patches and Scripts. - StrigiService & > KInotify > To: "Vishesh Handa" <[email protected]>, " Sebastian Tr?g " > <[email protected]> > Cc: [email protected] > Message-ID: > > <2093337748-1272631370-cardhu_decombobulator_blackberry.rim.net-1372199...@bda188.bisx.produk.on.blackberry> > > Content-Type: text/plain; charset="Windows-1252" > > F > Carlos > > -----Original Message----- > From: Vishesh Handa <[email protected]> > Date: Fri, 30 Apr 2010 17:37:03 > To: Sebastian Tr??g<[email protected]> > Cc: <[email protected]> > Subject: Re: [Nepomuk] Bugs, Patches and Scripts. - StrigiService & KInotify > > _______________________________________________ > Nepomuk mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/nepomuk > > > ------------------------------ > > _______________________________________________ > Nepomuk mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/nepomuk > > > End of Nepomuk Digest, Vol 9, Issue 1 > ************************************* > _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
