On Thu, 23.10.14 08:15, Aleksander Morgado (aleksan...@aleksander.es) wrote:
> That's a good one indeed; coalescing events in that way in the kernel > looks quite a sane approach. Still, one single process in userspace > doing all the control of what changed when (like FSEvents does) may > actually behave much nicer, as other processes could ask for all > changes coalesced since a specific timestamp (e.g. since that process > was run). Not thinking in Tracker here, think of a program which runs > sporadically, but when it runs it wants to know what changed since the > last time it was run (e.g. a backup app). This is really a file system feature, and btrfs already provides that. > Anyway, please remember that being privileged isn't the only reason > why Tracker can't use fanotify. It's API being fd-based, it works on > existing open files only; e.g. it won't notify file deletes or move > events, among other things. If we want some recursirve monitoring > approach with all CREATE/UPDATE/DELETE/MOVE events, something new > needs to be implemented, or inotify somehow improved to handle that. I don't think fanotify's interface couldn't be fixed to also generate useful events for deletion/moving. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
