Should RISC OS flush files to storage on close?

The PRM as included with DDE 27 states that for OS_File 0 “Any modified data held in RAM buffers is first written to the file(s).” and FileSwitch calls FSEntry_Args 6 (flush to storage) for files before closing them.

However:

• The wiki does not contain any requirement the data should be written immediately.
• “written to the file(s).” is not defined and is used an alternative sense the documentation of OS_GBPB and OS_BPut.
• When supported by the filing system, other filing system calls do not contain an implied flush, for example writing whole files with OS_File.
• RPCEmu HostFS does not implement FSEntry_Args 6, and therefore fails to flush on close or an explicit flush.
• Sunfish has a stub implementation of FSEntry_Args 6, I don’t know if it’s always synchronous or broken.
• Other operating systems don’t flush to storage on close.
• Synchronous flushing on close can seriously reduce performance, I have observed 23% to 74% slowdown on RISC OS ROM builds.
• It is not specified whether FSEntry_Args 6 may return before completing the flush.

Does anyone know of any programs that rely on flush on close to preserve data integrity in case of power failure etc?

What is the behaviour of other existing filing systems?

Would it be acceptable for a RISC OS filing system not to flush to storage on close by default? An special field option could be used to enable a backward compatible mode, and FileSwitch would need to be changed not to call FSEntry_Args 6 on close if requested.

I think that when DiscKnight was in development I remember people saying that RISC OS tended to be more reliable that Windows when it came to the filesystem not getting in a mess, but that will be because of the fact that most operations are flushed when the file is closed. I can see that caching more and flushing less would have a benefit in performance, but given the fact that a badly-written application can cause the whole machine to seize up without any way of regaining control, it would have some downsides too.

Of the non-FileCore filing systems, aside from those you have already mentioned I should think FAT32FS is probably the most heavily used. I think it does not write the FAT back at every possible opportunity and possibly has caching of file content on write as well.

DiscKnight was written around 2000 so that would be contemporary with Windows 98/ME. Modern filing systems such as NTFS, Btrfs and Ext4 are more robust. However filing system consistency was not the point of my question.

but given the fact that a badly-written application can cause the whole machine to seize up without any way of regaining control, it would have some downsides too.

Not a problem if the cache is outside RISC OS controlled by some operating system with full memory protection.

… FAT32FS is probably the most heavily used. I think it does not write the FAT back at every possible opportunity and possibly has caching of file content on write as well.

The documentation does state there is write behind caching and examination of the source reveals it ignores FSEntry_Args 6 and does not flush on close either.

DOSFS, ArcFSr/w, TBAFS, and StrongHelp are also broken, I’ve verified that OS_Args 255 is not propagated down to the underlying filing system.