Hi there,
2013/2/22 Vishesh Handa <[email protected]> > > > On Fri, Feb 22, 2013 at 11:47 PM, Simeon Bird <[email protected]> wrote: > >> Hi Gabriel, >> >> On 22 February 2013 08:55, Gabriel Poesia <[email protected]>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 >
_______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
