<div dir="ltr"><div dir="ltr"><div>The test case proves that it does.</div><div><br></div><div>The comment of the method is, </div><div><br></div><div>    "When writing, flush the current buffer out to disk." <br></div><div><br></div><div>I know what filesystem I deploy to, but Squeak appears to be silently ignoring this (rather important) expectation about #flush, that its own comment presents.</div><div><br></div><div>  - Chris</div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 12, 2020 at 6:15 PM Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Chris,<br>
<br>
Do you expect #flush to write the changes to disk?<br>
<br>
Levente<br>
<br>
On Sun, 12 Jan 2020, Chris Muller wrote:<br>
<br>
> 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<br>
> 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<br>
> of the contract which causes the test to fail.  This functionality is important to avoid corrupting databases.<br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> Best,<br>
>   Chris<br>
> <br>
></blockquote></div>