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.

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