[Nepomuk] Review Request 109078: Add a base class for the file watcher back-ends

[Simeon Bird]

Hi Gabriel,

On 22 February 2013 08:55, Gabriel Poesia <gabriel.poesia at gmail.com> wrote:

> - fanotify is completely silent regarding moves and deletes - it gives no
> clue something happened. It doesn't catch any other event related to the
> directories involved (file unlink, for example). Thus, it would need
> KDirNotify as a complement, which yes, only reports things done via kio.
>

None at all? Not even a directory open? If using, eg, dolphin or other kio,
will the directory reliably get opened (for listing) before a move takes
place?

- The fanotify_init man page confirms that you need root privileges
> (specifically, the CAP_SYS_ADMIN capability), and says that this constraint
> might be relaxed in the future. But, at least currently, yes, we'd need a
> root daemon even to watch $HOME.
> - I couldn't get the "directed" mode to work. This is the mode in which
> you would presumably only receive events from the directories you mark. It
> should just be a matter of changing a couple of parameters in
> fanotify_mark, but I didn't get it to work. If it really doesn't work,
> we'll need to manually filter global events (as I get here about 30 "open"
> events for /etc/passwd per second, for example).
>

Ouch. Does filtering on event type work? ie, can you listen to just
CLOSE_WRITE events? Also, is it not working, or is it just not working
recursively?

I can see instances where a kDirWatch backend might work, if it can perform
better than 1 million inotify watches - but I can't see it as a default,
because a careless mv or rm would cause problems.

Simeon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20130222/ab4523a3/attachment.html>