On Mon, Aug 01, 2005 at 06:18:23PM -0400, John McCutchan wrote: > On Mon, 2005-08-01 at 17:14 -0400, Daniel Veillard wrote: > > On Mon, Aug 01, 2005 at 04:11:45PM -0400, John McCutchan wrote: > > > Yo, > > > > > > dnotify4.py is broken. The test creates a file, then watches it as a > > > directory, and expects to get a DELETED event. This is screwy. What > > > should happen is that the monitor fails. > > > > it is the expected behaviour from the applications at this point. > > What applications expect to be able to watch a directory as a file?
An application which started monitoring a non existent resource which was (re)created as a file for example. If you look at the efew examples from the SGI documentation they show this kind of examples. http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=bks&fname=/SGI_Developer/books/IIDsktp_IG/sgi_html/ch08.html "Example: A client monitors a directory containing some files. Another program deletes the directory, then creates a new file with the same name as the directory." and I think I remember debugging nautilus and seeing this happening. > > They worked fine until now on dnotify and inotify back-ends. They > > reflect potential application expectations. Maybe those are not > > reasonnable but if the test must be changed that need to be discussed > > beforehand not after the commit breaking them. > > They worked fine on _your_ machine under your load. Many of the tests Ahum, you told me that they passed in your inotify tests too ! I'm sorry if you are disapointed, but denial is not a correct way to process. > (especially the flood tests) are racey. When you are testing for flood, very likely, let's fix the tests so they pass again but in a methodical fashion after having seen what is the problem and verified tha all changes make sense and result will pass on the multiple backends. > you expect a certain number of write events within the test time. But if > load is high, the write thread might not get scheduled in the way your > test assumes, and the number of events will be off. yes, this is not the problem encountered in the regression test failing. So this is not a justification to ignore it. > Also, looking at the dnotify kernel code and considering the DELETE > event. There is nothing that guarantees that by the time you receive the > DELETE event in gam_server the file will actually be removed from the > directory tree. So far that expectation has never be seen as broken in normal testing. To me it's a kernel bug like inotify bug you fixed 2 weeks ago it may just be a race instead of being systematic. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ Gamin-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gamin-list
