> On Fri, Aug 26, 2005 at 08:11:23PM +1000, TomPh wrote: > > For your review, attached test-cases 13 and 14 each include various > > tests for links to dirs and files/non-dirs, respectively. The > > corresponding results files have my best guess of what they should > > be. Haven't been able to achieve those results, with any server > > backend that works on linux. Nor have I got around to figuring out > > FAM. > > Well I don't think it makes sense to add test if we know they would > fail and we don't have a good idea of what the actual behaviour > should be.
Indeed. I was hoping that some of the crew with more history than me would think about and comment on what the results should be, before anyone takes a shot at making gamin pass the tests that we end up with. > > The link-test patch provides for making links, and changing their > > ownership (to get around prohibitions on changing link permissions). > > Incidentally, it adds a test for more-reports-than-expected, which > > shows up one or two of the existing basic test-cases, but not > > fatally so. > > I don't know if this is what you meant, but applying your patch > makes "make tests" fail while it was passing before. So well, I won't > apply it. You can split the part adding the new commands which is a > good idea. For the other part forcing failures on existing tests, > suggest separately the patch and explain why you think "make tests" > should be breaking from the very first test... I have a hard time > understanding how this can be a good idea. Too-many reports can be just as damaging for a client as not-enough, as you will well understand. Particularly with the link-related tests, the prospect of superfluous reporting is increased. Hence the addition of a check for that outcome. With that check in effect and running 'make tests', here I see extra reports for basic test 10 only, as follows: running test 10 *** ../tests/result/10 2005-05-12 21:38:22.000000000 +1000 --- result.10 2005-08-26 23:00:07.000000000 +1000 *************** *** 6,14 **** --- 6,16 ---- 1: /tmp/test_gamin Exists: NULL 1: subdir Exists: NULL 1: /tmp/test_gamin EndExist: NULL + expect line 7: expected 2 events but got 3 monfile /tmp/test_gamin/subdir/foo 1 2: /tmp/test_gamin/subdir/foo Exists: NULL 2: /tmp/test_gamin/subdir/foo EndExist: NULL + expect line 10: expected 1 events but got 2 cancel 0 2 1: /tmp/test_gamin Acknowledge: NULL append /tmp/test_gamin/subdir/foo Both of those extra reports look to me like they are right, and indicate a problem with the results file, not with gamin's performance. So fix the results file ... > > And it no longer stops the test when the no. of events is wrong. > > That occasionally caused havoc when thing(s) created in a test were > > not cleaned up at the end of the test. > > "make tests" was removing remains that was okay. Basic test 11 does not exit cleanly when run against --disable-kernel. In turn, that stuffs up most of the rest of the basic tests in that configuration. Tom _______________________________________________ Gamin-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gamin-list
