I did indeed have the wrong idea from only having skimmed that thread,
thanks for clarifying.  I'm glad to know flush wasn't on the chopping block
afterall.  :)

 - Chris

On Mon, Jan 13, 2020 at 4:44 PM Phil B <pbpublist at gmail.com> wrote:

> Chris,
>
> FWIW, if it's the thread I think it is, you got the wrong impression from
> the discussion.  The assertion was that the flush/close/reopen dance on the
> changes file was no longer needed, *not* that flush was no longer
> necessary.  The flush was the part that we kept! (i.e. the argument was
> that it's no longer the 90's and that we should trust flush to behave as
> expected)
>
> Thanks,
> Phil
>
> On Sun, Jan 12, 2020 at 6:18 PM Chris Muller <asqueaker at gmail.com> wrote:
>
>> Magma has been stable in 5.2 for a long time under an older VM, all tests
>> pass.  But by changing ONLY the VM (not the image) to the new
>> release-candidate, it fails the forward-recovery test.  This test tests the
>> scenario of a server failure during mid-write.  Unless I change
>> StandardFileStream>>#flush as in Files-cmm.182, the recovery data which
>> Magma relies on #flush to ensure is preserved is, in fact, not preserved.
>> It appears to be a breakage of the contract which causes the test to fail.
>> This functionality is important to avoid corrupting databases.
>>
>> I saw a discussion on the Cuis list in which someone was asserting that
>> flush is no longer necessary(!!), and made a vague reference to a "thread
>> on squeak-dev" which I never found.
>>
>> I hope this is just an oversight, otherwise I'll have to rely something
>> like Files-cmm.182, which is half the speed of the old #flush.
>>
>> Best,
>>   Chris
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200113/32b1d41c/attachment.html>