The 2.6.37 kernel is out

Posted Jan 5, 2011 4:04 UTC (Wed) by foom (subscriber, #14868)
Parent article: The 2.6.37 kernel is out

So, does that mean fanotify can actually do something useful now, like monitor changes in a directory tree? Is a superset of inotify yet?

Last I looked, it couldn't notify on addition or removal of a file in a directory, which seems to me to make it just about completely useless for everything other than a "virus scanner". And I *really* don't understand how the heck a new API which is very similar to inotify, yet has a mostly-overlapping-but-slightly-different set of features got accepted. If you want both sets of features, what, you should just use both file watch APIs at the same time? Come on.

Anyone want to explain to me how this isn't a complete disaster?

to post comments

The 2.6.37 kernel is out

Posted Jan 5, 2011 4:48 UTC (Wed) by JohnLenz (guest, #42089) [Link] (2 responses)

You can see file addition by watching for OPEN events. For deletion, how would that work? fanotify is a file monitoring interface, not a path monitoring interface. How would you deal with hardlinks? What if a file is hardlinked into two paths in a directory and one of the hardlinks is removed, would you still create an event? What about if the file is unlinked but a program still has an open file descriptor? Also, fanotify passes you a file descriptor so the file couldnt't be deleted yet when you receive the delete event. Remember, the file is not deleted until all file descriptors are closed.

It sounds like we should perhaps have an API for path monitoring events or something which shows path events like creating hard links, creating soft links, unlinking, renaming, etc. But I see no reason why this should be done in fanotify, since fanotify is a file change interface

The 2.6.37 kernel is out

Posted Jan 5, 2011 5:36 UTC (Wed) by foom (subscriber, #14868) [Link]

> For deletion, how would that work?

I'm confused as to why you would ask this: it's not like that's an brand new feature -- these things **already work in inotify**. The new features of fanotify are nice (especially the recursive watch, but also the presence of a pid field, and it being able to hand you an open fd), but why did that come at the expense of the features inotify already had?

So I guess I still have no idea what fanotify is really useful for as it stands. I thought it could be a better interface for doing a real-time-rsync, or doing backups of your whole disk, or perhaps a file indexer (doing manual recursion with inotify for a whole disk is kind of a pain, and leads to lost events...). But it can't be used for any of that.

So, it's not at all a better inotify. It's something completely different with a bunch of features lots of people wish inotify had, but without the features people already use (and need) in inotify.

The 2.6.37 kernel is out

Posted Jan 5, 2011 7:02 UTC (Wed) by ncm (guest, #165) [Link]

Directories are files. Deleting a file or link means changing the directory the file was linked from.

The 2.6.37 kernel is out

Posted Jan 5, 2011 14:19 UTC (Wed) by mezcalero (subscriber, #45103) [Link] (3 responses)

fanotify is useful for at least three use cases where inotify wasn't useful at all: for indexers/crawlers, for readahead implementations, and for antivirus solutions. All these three need recursive looks and in the last case synchronous events. fanotify delivers that, inotify doesn't.

Right now, inotify is a lot more useful when watching particular directories (i.e. a nautilus window which shall be a live view on some directory), for most other things fanotify is the better choice.

The 2.6.37 kernel is out

Posted Jan 5, 2011 15:36 UTC (Wed) by foom (subscriber, #14868) [Link] (2 responses)

I don't see how you can possibly use it for an indexer. Of course, recursive watches are a great idea -- and if they were added on top of the functionality inotify provided, that'd be wonderful. Users have been asking for that for a long time.

But, for an index generated by the indexer to be useful, it needs to be able to tell the user where the file with the searched-for-content is located -- so it needs to be notified about renames too, which fanotify doesn't provide. Am I wrong?

Boot-time readahead and antivirus is such a narrow solution-space that I don't see how this whole new infrastructure and API is justified if it can only really be used for those two things.

The 2.6.37 kernel is out

Posted Jan 5, 2011 18:18 UTC (Wed) by larryr (guest, #4030) [Link] (1 responses)

Can renames be detected via directory changes, similar in some sense to git rename "detection"?

The 2.6.37 kernel is out

Posted Jan 6, 2011 3:03 UTC (Thu) by foom (subscriber, #14868) [Link]

I do not have a 2.6.37 kernel installed to test, but my understanding is that renames cause no events to be emitted at all.