Comment 20 for bug 817326

This is a tricky area. It is fine to ask people to call fsync like drunken sailors on ext4 or btrfs - the costs are low; however for ext3 systems an 'fsync' can take many seconds to complete (if one has not been run recently) during which the entire system is un-responsive to I/O and the user feels like everything has crashed/locked. There is a monster kernel I/O bug about this IIRC that never goes anywhere.

So - it is a nuanced issue. We should look at what sequence we are using to re-write that file.

IIRC, if we use an atomic 'rename' then we should be guarenteed to get either the old or the new file, and not a zero length one; so prolly we should do that. Though of course this interacts nastily with the tangled locking code (no doubt).

Anyhow, I'm sympathetic to the idea of an fsync; except for the still rather widely deployed ext3 world where it is a potential "LibreOffice wedges my machine when I save" problem that is a royal PITA. Of course, for ourselves, we could do the 'fsync' aynchronously; with some horrible 'fsync thread', but ... it's all rather a mess.

We'd need to see if 'rename' will work at all with the locking semantics, and whatever odd-ball remote file-systems we're supposed to work with.