desktop-packages team mailing list archive

[Michael Meeks <817326@xxxxxxxxxxxxxxxxxx>]

> After powering up, the GEdit document is intact and contains the latest
> content, whereas the LibreOffice document is gone forever.

Thanks for testing. This is as expected, unless we use 'rename' - and
the code needs fixing to do that. *Unfortunately* the code is far worse
than a rats nest here.

Using 'rename' seems like an easy & trivial thing to do right ? it is
the elegant solution to avoiding 'fsync' - but this is not really so. It
is fairly easy to create a file-system for which we have no ability to
create files in the same directory that can be renamed over the top -
and finding other directories on similar file-systems for which 'rename'
can validly replace a file in another directory is a twisted mess of
nastiness. In these cases we -have- to open that file, write stuff to it
- and then we can't call fsync because it is a "bust your system
interactivity, break your burning DVD, jitter your sound playback, and
make people think LibreOffice kills babies" syscall on old file-systems,
where 'old' means 'widely deployed' :-)

Worse - there is no standard library out there that wraps 'fsync' into a
'sane_fsync' that will tell us what file-systems underlies the file, and
ensure that we are only calling fsync where it is safe (cf. above). If
some enterprising kernel hacker wants to create a nice, ultra-liberally
licensed library that turns a dev_t into a boolean: int
is_it_safe_to_fsync (dev_t *t); then I'd be more than happy to see it
used un-conditionally in our system-abstraction for Unix / Linux. Which
would prolly solve the problem. AFAICS dev_t's are pretty useless;
perhaps we'd need to parse /proc/mounts and combine that with the
horrible stat walk we already do to determine file-system type, and then
start doing string munging: "ext4" - safe to 'fsync', "btrfs" - prolly a
good idea to 'fsync' - or is it ? perhaps only > some version of btrfs,
and for ext3/ext2 etc. there is no need - they tend not to wantonly
loose your data ;-)

-- 
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