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

[Gabriel Poesia]

Hi there,


2013/2/22 Vishesh Handa <me at vhanda.in>

>
>
> On Fri, Feb 22, 2013 at 11:47 PM, Simeon Bird <bladud at gmail.com> wrote:
>
>> 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?
>>
>>
Unfortunately, not even a directory open. If I open the directory using
Dolphin, I get a file open event in the directory and all its files. But
nothing happens if I move a file :P

  - 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?
>>
>
Yes, filtering on even type works. And listening only to CLOSE_WRITE events
filtered a large portion of the non-interesting accesses I was getting
here. I hadn't tried that before. But the "directed mode" seems to not work
at all. If I try to watch only a single directory, no matter if I list it,
touch it, delete it or create a file in it, nothing happens. Maybe I'm just
misusing it, but it should be so simple...


>> 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.
>>
>
> Lets use the correct terminology - It's KDirNotify. KDirWatch is KDE's
> abstraction over inotify, dnotify, fam and others. We do not care about it
> cause it doesn't support move events.
>
> KDirNotify is the dbus notification api which we care about.
>
> ----
>
> Since fanotify requires root access, it really doesn't seem like a viable
> option.
>
> How about we just stick with just inotify or inotify + kdirwatch? I know a
> stray move might remove stuff, but it does have significant advantages as
> well.
>
>
Wait, KDirWatch or KDirNotify? hehe


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