desktop-packages team mailing list archive

[Michael Meeks <817326@xxxxxxxxxxxxxxxxxx>]

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 Desktop
Packages, which is subscribed to libreoffice in 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

Status in LibreOffice Productivity Suite:
  Confirmed
Status in “libreoffice” package in Ubuntu:
  Confirmed

Bug description:
  I was working on a document in LibreOffice today while my battery was
  low and so I was frequently saving, which I thought would help me if I
  lost power. However, when I eventually did lose power and later
  rebooted, the document had become 0 bytes long. LibreOffice was not
  able to restore the auto-saved copy either. As a result, I have lost a
  whole week of notes for one of my courses.

  After researching online, it seems that this is caused by the
  application not calling fsync() (or fdatasync()) when saving files.
  Due to delayed allocation in modern filesystems, there is no guarantee
  that the new file's data has actually been written to disk unless the
  application calls fsync. So if an app writes a new file and replaces
  the old one with it without fsync'ing the new one first then there is
  a window of opportunity during which a power failure will result in
  the loss of BOTH versions of the file. In ext4 this window is also
  much larger than in ext3.

  Theodore Tso blogged about this at http://ldn.linuxfoundation.org
  /blog-entry/delayed-allocation-and-zero-length-file-problem and
  http://www.linuxfoundation.org/news-
  media/blogs/browse/2009/03/don%E2%80%99t-fear-fsync. He strongly
  recommends to call fsync in this situation.

  Please update LibreOffice to fsync() saved files so that other users
  do not lose their data like I did.

  ProblemType: Bug
  DistroRelease: Ubuntu 11.04
  Package: libreoffice-core 1:3.3.2-1ubuntu5
  ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
  Uname: Linux 2.6.38-8-generic x86_64
  Architecture: amd64
  Date: Wed Jul 27 21:37:02 2011
  InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429)
  ProcEnviron:
   LANGUAGE=en_US:en
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: libreoffice
  UpgradeStatus: Upgraded to natty on 2011-04-29 (89 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/df-libreoffice/+bug/817326/+subscriptions