On Wed, Mar 5, 2008 at 9:15 PM, Ove Kaaven ovek@transgaming.com wrote:
James Hawkins skrev:
The tests that now pass with native cabinet dll are test_continuouscab (which is similar to what you're trying to test). The point of maxsize is so that it creates continuous cabs...there's no other way to do it, and builtin doesn't create continuous cabs at all.
No? Then I really wonder what those hundreds of .cab files it creates from that 50k testfile is, if not continuous cabs. What else are they?
Sorry, I meant that it doesn't create the compressed continuous cabs that the tests expect.
The answer to your question is no, because there is no test currently that runs down the code path you are fixing.
Looks like it takes an order of magnitude more time writing test cases for this stuff than actually fixing that darn bug (fixing the bug took 2 hours, figuring out how to put a working test case together (trying to take differences between native and builtin cabinet into account) has taken me all day, probably longer).
You have to keep in consideration all the time that has been saved fixing bugs later down the road because the test cases have kept regressions to a minimum (and just flat out wrong code being added).
Here's what I managed to put together that seems to trigger the problem condition... the cab extraction sequence was somehow different in my real-world case, so I had to fudge this testcase a little by packing a third file into the continuous cab. So what do you think about this test, then?
Looks good to me, as long as the test fails without your fix and succeeds with your fix (with the cabinet override of course). When submitting the tests to wine-patches, make sure you add todo_wine to the failing tests (because of cabinet).