ev_stat inotify implementation might miss events

Marc Lehmann schmorp at schmorp.de
Thu Jan 28 01:47:30 CET 2010


On Wed, Jan 27, 2010 at 11:18:18AM +0100, Yoann Vandoorselaere <yoann.v at prelude-ids.com> wrote:
> > fsnotify gives you an event for each change, and is synchronous. inotify
> > does not and is asynchronous. fsnotify is usable for auditing, inotify much
> > less so. fsnotify requires privileges, inotify does not.
> 
> The point of the kernel code I copied in my previous mail was to show
> you that the system directly call fsnotify, which itself ping inotify.

Well, it's still asynchronous and doesn't give you one event per change,
so whatever your point was, it's irrelevant, or do I miss something?

> Again, Inotify can merge events of the same type together. Inotify
> guarantee to provide a notification for any event on a file (but there
> might be only one notification for 10 event of the same type).

That's kind of illogical. Inotify does not attempt to deliver all events,
events might get lost if the queue overflows.

> > Your problem is that you fail to understand inotify - it simply cnanot
> > give you one event for each change, this is impossible without it becoming
> > synchronous, introducing a security bug.
> 
> Marc, why don't you listen ? The original subject of this conversation
> is not Inotify, but rather that libev has a problem where it sometime
> won't call the application callback when Inotify has notified a change.

But I really don't see it. Everything points ot a usage bug, or a
misunderstanding.

> Instead of concentrating on the problem, you keep routing the discussion
> in a void technical conversation where you insist that libev has no bug.

Well, I was trying to help you by making you understand. But since that's not
appreciated, go help yourself then.

> I can confirm this issue, I have it here and can reproduce it reliably.

Which issue? You consistently failed to provide any evidence for a problem.
All your theories are simply wrong, and so far, you were completely unable to
even describe the problem you might encounter.

> I confirm Inotify send the notification, and that libev ignore it (for
> reason I already described in earlier mails).

Then describe which notification inotify sends which libev then ignores?

> I'm trying to help improve your project by escalating bugs.

Maybe, but you are not helping by telling me your wrong theory of the day
of what's wrong in libev, when this is obviously not true.

What I need is *evidence* and a description of the *problem*.

> great, but like any software, it might happen that a bug is found in the
> code. 

Yes, and a bug has been found, except it doesn't match anything in your
description. I asked you to try out the cvs version, which you have ignored.

You are not helping by inventing fantasy issues and makign your own closet
theories that are obviously bollocks.

You need to be *constructive*. All you do currently is claim this and that
line of code is wrong i libev. 

To be constructive, you have to give *evidence* of what event is lost.

> If you have no interest in that, or you react by insulting people, then

Well, I do neither, so why do you make any such implications? Everybody can
see that you have no clue about inotify. It's more difficult to verify that
you claims about whats wrong in libev are bollocks, but I tell you they are.

Instead of verifying (or not) that your problem is caused by an *actual* bug
in libev, you just come up with more wild theories.

I haven't insulted you yet, but I have to say, you are an idiot.

Get to your senses and talk facts, give evidence, drop all those weird
conspiracy theories.

> it is no problem for me to fix the bug for myself and maintain my own

Well, you have certainly been incapable of even describing a bug, and all
your feeble atemtps at fixing introduce race conditions into working code.

> > Point being? How do I magically find the new name of the file?
> 
> My previous explanation was confusing, so let me rephrase: I was talking
> about a way to keep monitoring files that have been moved (and not
> deleted, as I previously mentioned).

There is no portable way to do that. First problem: how do you find the
file after it has been renamed?

> You can do this with or without Inotify support.

Not with standard POSIX features.

> In order to emulate that (no inotify), you may provide a function so
> that an application can _optionally_ provides libev with a file
> descriptor used to access the file. 

That keeps the file open and contradicts the documentation.

It would break libev completely.

Obviously, that's not acceptable, do you see why?

It's also trivial to implement yourself.

> This doesn't provide a way to get the new filename when Inotify support
> is not enabled, but this provides a way to keep monitoring files that
> are moved around, for application that have an open FD referencing them.

It would also break libev. So your claim is "youc na do it without inotify,
except you can't".

Another of your wild claims evaporates.

> [skipping the pile of insults over here]

The only one insulting so far were you, sorry.

If you want to be taken seriously, stop making idiotic claims about inotify,
libev, or some miracle algorithm you found which of course doesn't even work.

If you actually found a bug in the current code, bring evidence, not hot
air. Anything else is not helping.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\



More information about the libev mailing list