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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/817326 Title: [Upstream] Previously-saved LibreOffice document lost by power outage (became 0 bytes long) - LibreOffice should call fsync To manage notifications about this bug go to: https://bugs.launchpad.net/df-libreoffice/+bug/817326/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
