> On Feb. 21, 2013, 3:32 p.m., Simeon Bird wrote: > > So, the patch looks fine, but, while not wanting to be negative, I want to > > ask if this project is really the right direction? > > KDirWatch uses either inotify or stat internally, so I don't see how it > > would be better than using inotify? > > > > fanotify looks quite useful, but we would still need to watch everything > > with inotify for moves, no? > > Also I found on the kernel list that fanotify has some fairly large bugs: > > http://article.gmane.org/gmane.linux.kernel/1441629/match=fanotify > > http://thread.gmane.org/gmane.linux.kernel/1224800/focus=1439656 > > > > Particularly the fact that the first has not been found before suggests to > > me that not many people are using it, > > and that we will hit many more bugs. Of course, bugs can be fixed, but it > > suggests we should move carefully... > > > > I'm not saying don't do it, I'm just wondering if the wiki is really the > > right approach, before a lot of code gets written. > > Sorry if this is undue pooh-pooh. > > > > Simeon
Hey Simeon I was thinking more along the lines of allowing the users to use any combination of the following - inotify, kdirnotify( a dbus based api ) and fanotify. There are two big problems with inotify - * Non-recusrive watches * Having to watch both the source and destination in order to receive file move events. KDirNotify provides file deletion and move events, but only for applications that use KIO for doing so. Fanotify allows recursive file watches, but does not provide deletion or move events. If one wanted, one could use either - inotify + KDirNotify and avoid having to watch everything. Or maybe fanotify + KDirNotify and then one wouldn't even have to install so many watches. I though it's high time to provide the users with an option to change backends if they want to. Maybe the default could be inotify + KDirWatch? Or we could just stick to the inotify only backend as possible. What do you think? - Vishesh ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109078/#review27847 ----------------------------------------------------------- On Feb. 21, 2013, 2:05 p.m., Gabriel Poesia wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/109078/ > ----------------------------------------------------------- > > (Updated Feb. 21, 2013, 2:05 p.m.) > > > Review request for Nepomuk and Vishesh Handa. > > > Description > ------- > > This is about this task: > http://community.kde.org/Projects/Nepomuk/4.11#File_Watcher > > This abstract FileSystemMonitor class is basically the generic interface > extracted from KInotify. > It also has a method to ignore paths based on a RegExpCache filter list, just > like IgnoringKInotify. > > > Diffs > ----- > > services/filewatch/filesystemmonitor.h PRE-CREATION > services/filewatch/filesystemmonitor.cpp PRE-CREATION > services/filewatch/test/CMakeLists.txt 8b6ebe6 > services/filewatch/test/filesystemmonitortest.h PRE-CREATION > services/filewatch/test/filesystemmonitortest.cpp PRE-CREATION > > Diff: http://git.reviewboard.kde.org/r/109078/diff/ > > > Testing > ------- > > The empty test that includes it compiles. > > > Thanks, > > Gabriel Poesia > >
_______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
