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 al...@redhat.com alexander.lars...@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! _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list