James Hawkins skrev: > On Wed, Mar 5, 2008 at 9:15 PM, Ove Kaaven <[EMAIL PROTECTED]> 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.
Well, that's because create_cc_test_files expect to get 2 cab files, not 600, and so the "caesar" part proceeds to overwrite the 3rd in the series, rendering the whole series unreadable. By adjusting the max size so that only 2 (uncompressed) cab files are created, most of the todo tests appear to run fine. Just changing the file name might also work. (Actually I don't see any reason your tests would really need to depend on compression anyway, it's supposed to be a test of MSI, not cabinet.) >> 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). Actually, I think it works with both builtin and native cabinet, because my create_cc2_test_files creates uncompressed continuous cabinets, which both builtin and native seem to handle. (I was almost forced to use uncompressed anyway, because create_file creates sparse files, which compresses into almost nothing, which made it difficult to predict whether the contents would be distributed the way I needed...)