Hi David,

On Sat, May 21, 2016 at 10:15 AM, David T. Lewis <lewis at mail.msen.com>
wrote:

> On Sat, May 21, 2016 at 09:50:16AM -0700, tim Rowledge wrote:
> > We have an interesting problem in Pi-land where many teachers report
> kids losing their Scratch work (and other, but I don???t get to fix that)
> because of pulling the power before fully shutting down etc. This tends to
> put them off trying again, apparently.
> >
> > We already close files properly after writing out files but it seems
> that dear ol???unix likes to save actual writing for later, perhaps when it
> has time for a relaxing latt?? or whatever. It has been suggested that
> using fsync() might force the lazy writer to actually do its job properly,
> which seems reasonable. In thinking about where to add this I see a couple
> of obvious possibilities
> > a) a new primitive
> > b) add fsync() (suitably wrapped in case of non-availability) to the end
> of the sqFileFlush() called in primitiveFileFlush() code.
> >
> > I think I prefer b) personally but I???m happy to be educated. Possible
> probles insclude some OS??? not having a fsync option; so far as I can see
> Windows already uses a totally disjoint set of code.
> >
> > Can anyone think of bad things happening if I do this? Think of the
> children???.
> >
>
> I suspect that the problem lies elsewhere. The difference between fsync()
> and fflush() is basically that fflush() functions at the higher level stdio
> (C runtime lib) level, and fsync() is a system call at a lower level that
> operates directly on the file descriptor.
>

fflush and fsync are different.  fflush merely ensures that the stdio
buffers in the process are flushed to the kernel file state via write
calls. sync however ensures that kernel state for that file descriptor is
written to disc.  sync does this for all kernel file state.  I think Tim's
diagnosis and solution are correct.


> The unix file functions are written to the stdio level, so the existing
> call
> to fflush() is the right thing to do. I do not know if mixing a lower level
> call in with this would hurt anything, but it will not help anything either
> and it does not seem like a good thing to do.
>
> My guess would be that there is some path through the code in the image
> where
> you might be able to add a #flush to address the issue. This can have
> performance
> tradeoffs, but reliable would be better than fast in a case like this.
>
> Dave
>
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160521/ac0f614d/attachment.htm