Re: Is it a bug in Gio::FileMonitor?

[Alexander Larsson <alexl redhat com>]

On Thu, 2010-06-10 at 04:23 +0300, Владимир wrote:
> I said I listened to "all the events", not just some, in particular
> IN_ATTRIB stands for "File's metadata (inode or xattr) was changed.".
> That is, I used IN_ALL_EVENTS which stands for "Bitwise OR of all
> events.".

Then its a bit weird that you got zero IN_MODIFY events as 500 megs of
data was written to the file. 

>From the inotify faq:

 Q: What is the difference between IN_MODIFY and IN_CLOSE_WRITE?

 The IN_MODIFY event is emitted on a file content change (e.g. via the 
 write() syscall) while IN_CLOSE_WRITE occurs on closing the changed
 file. It means each change operation causes one IN_MODIFY event (it may
 occur many times during manipulations with an open file) whereas
 IN_CLOSE_WRITE is emitted only once (on closing the file).

So, if the copy was done with say a 64k buffer you should have gotten
8000 IN_MODIFY events.

You may of course chose to not look for IN_NOTIFY, but (just like I said
before) the inotify faq says:

 Q: Is it better to use IN_MODIFY or IN_CLOSE_WRITE?

 It varies from case to case. Usually it is more suitable to use
 IN_CLOSE_WRITE because if emitted the all changes on the appropriate
 file are safely written inside the file. The IN_MODIFY event needn't
 mean that a file change is finished (data may remain in memory buffers
 in the application). On the other hand, many logs and similar files
 must be monitored using IN_MODIFY - in such cases where these files are
 permanently open and thus no IN_CLOSE_WRITE can be emitted.

For gio its a bit worse here, because we can't rely on the existence of
IN_CLOSE_WRITE as many backends don't have that (they only have the
equivalent of IN_MODIFY). 

> I also think it's sad that instead of a reaction like "hey, he's got a
> point, this issue does make apps feel sluggish so we should
> investigate into it, after all even Java (7) which is also
> cross-platform doesn't suffer from this", there's instead quite the
> opposite reaction to not improve, like "if we do this, a bad side
> effect will happen (and if you prove we're wrong about it we'll find
> another noble excuse) or just say nothing is perfect".

I did say you had a point (we should look into why the delay is so large
and i did say the inotify code was not ideal), but that doesn't mean I
have time to dig into this immediately. Also, it doesn't mean that the
issues I've talked about are without merit. But I have no interest in
further arguing this with you.

> And thanks, I already went for inotify because clients/users want
> quality, not noble excuses.

Good for you.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a fast talking overambitious farmboy searching for his wife's true 
killer. She's a green-fingered mutant former first lady from beyond the grave. 
They fight crime!