Re: [gamin] Test suite problems

[Daniel Veillard <veillard redhat com>]

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/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/