[Upstream] Previously-saved LibreOffice document lost by power outage (became 0 bytes long) - LibreOffice should call fsync

[Tristan Schmelcher]

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)

[echelon (echelon-y)]

I just lost a report I've been working on for four hours due to this bug. My machine crashed very shortly after saving, and upon reboot LibreOffice asks if I want to recover the file (it always asks this) but fails. The file is now at zero bytes and there is nothing in ~/.libreoffice/3/user/backup

Linux x120e 2.6.38-11-generic x86_64

This is a very serious bug. I might lose my head over this one.

[Tristan Schmelcher (tschmelcher)]

@echelon Sorry to hear this caught you too. You should mark this bug as affecting you too so that it will become Confirmed and will get attention sooner. Just click the line at the top that says "This bug affects 1 person. Does this bug affect you?"

[Tristan Schmelcher (tschmelcher)]

I am using LibreOffice 3.3.3 on Ubuntu 11.04 amd64 (distro-provided packages). Recently I was working on a document in LibreOffice 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.

Forwarding upstream from Ubuntu bug at https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/817326

You can see evidence of more users encountering this at:
http://ubuntuforums.org/showthread.php?p=11215058
http://user.services.openoffice.org/en/forum/viewtopic.php?f=6&t=39666

[Davian818 (davian818)]

Since when filesystem issues are application concern?

[Tristan Schmelcher (tschmelcher)]

This is not a filesystem issue, the filesystem is behaving correctly. In order to persist data to disk (on _any_ filesystem), the application must call fsync(). This is part of the POSIX spec. By not calling fsync(), LibreOffice is basically _telling_ the filesystem that it is not important to retain this file in the event of a power outage.

[BadOmen (badomen02)]

Should not this bug be set to Importance: High?

Everyone is affected by it, it's just that most of the users will not know it before they lose all what they have written.
Using a office suite that can at any time, with a little bad luck, erase all you have written is not a reliable office suite.

I guess this is not just the libreOffice Writer, but the entire suite, that does not do this fsync when saving.

I read on internet that a girl had saved her document and then just turned off here computer by holding in the power button because she was in a hurry... It also triggered this error and here document was now a 0 byte file...

[Tristan Schmelcher (tschmelcher)]

I agree, but normally it is courtesy to let the developers assign the priority. You may want to comment on the upstream report at https://bugs.freedesktop.org/show_bug.cgi?id=40607 about the importance.

[Tristan Schmelcher (tschmelcher)]

Here's a decent example of how to fsync() from Java: http://android-developers.blogspot.com/2010/12/saving-data-safely.html.

Note that if using buffered I/O then you also need to flush the data before the sync().

[John-iglar (john-iglar)]

I'm adding a "me too" here. Our school is using Ubuntu and LibreOffice and we have had many students lose work due to this bug.

Repeat Tristan's comment - not a filesystem issue, but application.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45

[Eduard Hasenleithner (eduard-hasenleithner)]

Libreoffice is in the "main" section and the _default_ ubuntu office application. Not taking this bug seriously will give Ubuntu a very bad PR! This IMHO includes setting the importance to Critical ASAP.

As a side note/question: What about the operating system level workaround mentioned in Bug #317781, has it been removed from the linux kernel?

[tobi-wan-kenobi (tobi-wan-kenobi)]

Problem can be reproduced easily (tried on an Ubuntu 11.10):

1. Open LibreOffice
2. Create and save a document
3. Write busily and save regulary using Ctrl+S
4. "Shut down" the computer by removing the power cable

I fully agree with the previous comments that this is a *highly* critical bug, because of the potentially serious (I would even say fatal) consequences. I am pretty sure that users rely on the assumption that "saving" means "my data is safe".

In my opinion, this should be reflected by setting the bug to "Critical" and fixing it as soon as possible.

[Tristan Schmelcher (tschmelcher)]

@Eduard I suspect LibreOffice is saving the file in such a cavalier way that the kernel work-around is not even able to detect that it should be saved transactionally.

[GeoPezao (geopezao)]

I have lost the minutes of an important one-day business meeting due to this bug. Without this bug fixed I simply cannot afford to rely on libreoffice (in fact I wonder if anyone knowing this bug takes the risk to use libreoffice). I fully agree with the previous comments that this is a highly critical bug and that this problem should be fixed as soon as possible. I really do not understand why such a critical bug is still not fixed after 4(!) months.

[Fredrik Nyman (fredrik-nyman)]

I just lost a document I'd been working on for days. I saved it, closed LibreOffice, then suspended my system. This morning I woke up my system and the file was gone. Just like that. NOT happy.

[Fabián Rodríguez (magicfab)]

Thanks (to myself) for hourly backups, although I spent most of another hour finding out what happened.

Upstream is still marked "NEW" so I doubt this is getting the proper attention.

[penalvch (penalvch)]

Severity > Critical since this scenario causes data loss.

[Tlillqvist-k (tlillqvist-k)]

Why do you think an example using Java, on Android even (comment #3) has relevance for LibreOffice? Just asking in case you think LibreOffice is written in Java...

Also a disk crash causes data loss. If you are working on important documents, without doing backups to another device (preferrably a removable or remote one), they can't be that important after all.

Is LibreOffice the new dog that eats homework?

[Michael Meeks (michael-meeks)]

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.

[Normand C (gemnoc)]

As a stopgap measure, I suggest not relying on the auto-save and using "save as" and changing the filename everytime, for example appending v1, v2, etc. I'm guessing if the last used file is scrapped by an outage or suspend, the previous one won't.

[Tristan Schmelcher (tschmelcher)]

Yeah sorry about the Java comment, I thought for some reason that LibreOffice was written in Java. Ignore that.

Doing the atomic rename as Michael suggests is a good middle-ground between robustness and performance. ext4 in recent builds supposedly adds an fsync to that if it is missing.

[Björn Michaelsen (bjoern-michaelsen)]

[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html

[Jbf-faure-9 (jbf-faure-9)]

According to comments 6, 7 and 8, the relevant category seems to be enhancement.
LibreOffice works as designed but something could be improved when saving files.

Best regards. JBF

[sabine (a4a43959)]

I just lost a document I have been working on for weeks, due to the Ubuntu overheating-problem, which caused a power-failure, and then due to this bug in LibreOffice, which cost me weeks of work.
I am depending on Libreoffice due to the special features I require, which make it easier to write in a rare language, and would otherwise be difficult to accomplish.
I hope this will have a solution soon, as I cannot risk loosing any more work.
There is only version 3.4.4 available in the repositories.
No fixes with updates?
I appreciate your help!

[Tristan Schmelcher (tschmelcher)]

I'm not sure the enhancement category is the right fit here. I'm sure loss of data was not one of the design criteria, so it doesn't seem to me like this aspect of LibreOffice can be considered to be working as designed.

I'll try out 3.5.0 beta 1 when I get a chance.

[Tristan Schmelcher (tschmelcher)]

Tested 3.5.0 Beta 2 and the bug persists. My repro steps:

1) Open LibreOffice, type something, and save it.
2) Open GEdit Text Editor, type something, and save it.
3) In a terminal, run "sync". The previously-saved versions are now on disk.
4) Change the LibreOffice document and save again.
5) Change the Text Editor document and save again.
6) Pull out the power cord.

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

[Michael Meeks (michael-meeks)]

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

[Tristan Schmelcher (tschmelcher)]

(In reply to comment #13)
> 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.

I was actually looking into that recently as part of another project and it's pretty easy. Basically,

1) Stat the file to get the st_dev.
2) Stat each file in /dev/disk/by-uuid to find one with a matching st_rdev.
3) Run realpath() on that file. Now you have the device file holding the filesystem.

From there you can easily look up the filesystem type in many places, e.g. /etc/mtab, /proc/fs, or /sys/fs. Probably /etc/mtab is your best bet since it is a generic UNIX thing.

On non-Linux or on Linux without udev you could fall back to stat'ing each file in /dev rather than /dev/disk/by-uuid.

[Michael Meeks (michael-meeks)]

Hi Tristan,

> I was actually looking into that recently as part of another project
> and it's pretty easy. Basically ...

Sounds cool :-) any chance you can knock up a nice fragment of tested C code that would do this for Linux under MPL/LGPLv3+ that we can couple up ? We'd want to add that to sal/osl/unx/file.cxx (osl_syncFile) inside some #ifdef LINUX guard I guess.

Then we'd want to add an osl_syncFile to the end of our export logic, which is slightly more involved; I suspect ucb/source/ucp/file/filstr.cxx /closeOutput/ - anyhow - first steps first.

Turning this into an intermediate / easy hack with the above pointers :-)

[Tristan Schmelcher (tschmelcher)]

Actually on second thought there is a simpler and more robust approach, just run realpath() on the document file and then scan /etc/mtab for the longest mount point that is a prefix of the document's path. That way tmpfs and such can be detected correctly. That appears to be how df works.

[Tristan Schmelcher (tschmelcher)]

Created attachment 55617
Small utility to test if fsync() is desirable for a certain path

Here you go. Tested on ext3, ext4, tmpfs, "none" filesystems, procfs, sysfs, and bind mounts, including mount points that are renamed after they are mounted and mount points with whitespace in their paths. I hereby release this file into the public domain.

[Michael Meeks (michael-meeks)]

Created attachment 55644
sal fsync patch ...

Thanks Tristan ! you provoked me into doing something here, and thanks for the tips. As you say it shouldn't be so hard. I attach a sample patch to LibreOffice. The only real problem that remains (beyond removing the debug), is to work out -which- of the umpteen different entry points is actually doing the writing of our documents.

It is possible / probable that there is some 'transfer' or 'move' thing happening whereby we write data into /tmp/ and then in a second step zip it over the target [ prolly in the package/ code ].

With a bit more digging to find that, we should be able to hook this up (cf. my failures on that score in ucb/ ;-).

[Evan Peck (colors)]

Were you using the latest LibreOffice version?
The info says you were using LO 3.3.2.
"Package: libreoffice-core 1:3.3.2-1ubuntu5"
The latest Final release is 3.4.5 (libreoffice.org)
The latest in LP is 3.5.1.
I would recommend using 3.4.5 to avoid errors related to LO not calling functions

[Tristan Schmelcher (tschmelcher)]

FYI, the parse_mounts in your patch won't work for paths containing whitespace. The whitespace characters are translated into octal escape sequences in the file. You'd be better off using setmntent and friends, which handle that for you.

[Tristan Schmelcher (tschmelcher)]

@Evan See comment #26--I tested 3.5.0 Beta 2 too and it still repros.

[Evan Peck (colors)]

@Tristan Oh. What about 3.4.5?
(That is the latest final release on their website)

[Tristan Schmelcher (tschmelcher)]

Created attachment 55708
Small utility to test if fsync() is desirable for a certain path

Discovered a small bug in my code, attaching a fixed version.

[Michael Meeks (michael-meeks)]

Hi Tristan,

> FYI, the parse_mounts in your patch won't work for paths containing
> whitespace. The whitespace characters are translated into octal escape
> sequences in the file. You'd be better off using setmntent and friends,
> which handle that for you.

Doh - I should have read your code much more carefully; silly me. Any chance of a cleanup / simplify of my patch ? & a bit of hunting with gdb to find which bit of code is doing the final close on the output file so we can osl_syncFile it there ? :-)

Of course, you'd need a build - but it'd be much appreciated ! :-)

[C de-Avillez (hggdh2)]

Marking triaged.

@DonMick: please do not assign yourself to a bug's task unless you are actively working on fixing it.

[Tristan Schmelcher (tschmelcher)]

Not sure when I could fit that in ... I'll see.

[Michael Meeks (michael-meeks)]

Doing a bit more code reading; it seems that the likeliest place to add an osl_syncFile - or somesuch UNO call to either the ucb/ or package/ code is the SfxMedium code:

sfx2/source/doc/docfile.cxx (Transfer_Impl)

perhaps this, or hereabouts:

                // copy the temporary storage into the disk spanned package
                GetStorage()->copyToStorage( xStor );
                uno::Reference < embed::XTransactedObject > xTrans( pImp->xStorage, uno::UNO_QUERY );
                if ( xTrans.is() )
                    xTrans->commit();

but some stepping through in the debugger is needed there I guess.

[Tristan Schmelcher (tschmelcher)]

Created attachment 55932
gdb trace of all the calls to close(2) when saving a document

Seems reasonable. I used gdb to find all the stacks that call close when saving a file (in 3.4.4, since I didn't have time to build my own package with symbols). There's a lot of calls (27), but most are very similar. Transfer_Impl indeed appears in several, and SfxMedium in almost all of them.

I noticed that some of the calls are for backing up stuff. Ideally the backup(s) should be fsync'ed too so that a usable backup will be present even if a power outage occurs in the middle of saving the real file, since copying is not atomic like rename is.

[Michael Meeks (michael-meeks)]

A really useful trace - thanks for that ! :-) it seems that a load of these are related to the flurry of /tmp files that we create (apparently for no really good reason).

Re-running with:

diff --git a/sal/osl/unx/file.cxx b/sal/osl/unx/file.cxx
index aa6cc26..6b3c56c 100644
--- a/sal/osl/unx/file.cxx
+++ b/sal/osl/unx/file.cxx
@@ -1064,6 +1064,9 @@ SAL_CALL osl_closeFile( oslFileHandle Handle )
 {
     FileHandle_Impl* pImpl = static_cast<FileHandle_Impl*>(Handle);

+ fprintf (stderr, "Close on '%s'\n", pImpl && pImpl->m_strFilePath ?
+ pImpl->m_strFilePath->buffer : "<null>");
+
     if (pImpl == 0)
         return osl_File_E_INVAL;

Might show us which one is actually the file you saved as :-) interesting too to see the backup stuff there. It was great to see the osl_copyFile method being used too - there is a comment in the impl. saying it isn't used ;-)

[Michael Meeks (michael-meeks)]

Using my own patch for a save I got:

Close on '/tmp/lu4uaci5.tmp/lu4uaci9.tmp'
Close on '/tmp/lu4uaci5.tmp/lu4uaci9.tmp'
Close on '/tmp/lu4uaci5.tmp/lu4uacia.tmp'
Close on '/tmp/lu4uaci5.tmp/lu4uacib.tmp'
Close on '/tmp/lu4uaci5.tmp/lu4uacib.tmp'
Close on '/tmp/lu4uaci5.tmp/lu4uacib.tmp'
Close on '/tmp/.~lock.test.odt#'
Close on '/tmp/lu4uaci5.tmp/lu4uacia.tmp'
Close on '/tmp/test.odt'
Close on '/tmp/lu4uaci5.tmp/lu4uacia.tmp'
Close on '/tmp/lu4uaci5.tmp/lu4uacic.tmp'
Close on '/tmp/test.odt'
Close on '/tmp/lu4uaci5.tmp/lu4uaci8.tmp'
Close on '/home/michael/.config/libreoffice/3/user/5znZDX'

Makes you wonder what is going on: looks like an 'open and shut' case to me ;-)

I was saving as /tmp/test.odt.

HTH.

[Robertsteiner75 (robertsteiner75)]

I have my odt-files on a NAT system, which is accessed via NFS.

Today, my day was ruined because one odt-file which was open (by LibreOffice 3.5.0rc3 on a debian "Lenny" system) when I shut down the system yesterday was gone today without a trace. Thank god another odt-file that was also open is still there. Please note that I did not have a crash or power-outage, but just made a normal shutdown.

I'm not sure whether this is the same bug, because other users have reported that they had an empty file, but my file vanished completely. Maybe the other affected users could clarify this.

I've been using OpenOffice 2.4 for several years with the same NAT, the same NFS-setup, the same OS and the same odt-files - and I have never had dataloss.

Also, I might add that to categorize this bug as "enhancement" is really an insult - no bug can be worse than any bug that causes dataloss especially if complete files are deleted.

[Michael Meeks (michael-meeks)]

Hi Robert, sorry to hear about your data loss:

> I've been using OpenOffice 2.4 for several years with the same NAT, the same
> NFS-setup, the same OS and the same odt-files - and I have never had dataloss.

It is worth pointing out that this (missing fsync) is -exactly- the same in the OpenOffice code, so ... while it's absence might well be the cause of your grief, it's not different to what you had before.

GregKH managed to 3/4 persuade me that we should just call fsync() wherever and risk the wrath, frustration etc. of people blaming the kernel /file-system bugs for ext2, ext3 etc. and to some extent ext4/btrfs on us.

I'm inclined to do that I guess - and skip the fstab parsing etc.

[Robertsteiner75 (robertsteiner75)]

Hello Michael, thanks for your reply.

Please use fsync, even if it may cause some frozen GUI for a few milliseconds, keeping your data safe should be priority to *everything else*. And if only older Linux-systems are caught, even more so. (And I say that as a debian-Lenny user. Older installations are not upgraded to the latest LibreOffice versions that often anyway - and to be honest I was only interested in SVG, otherwise I would still be happily using OpenOffice 2.4) While I was somewhat "lucky" to lose only a few hours work (if the other file were lost, it would have been a week though...) other people on https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/817326 reported many days and weeks worth of lost data. I don't think that a faster GUI can make up for that, even if you add it up over a user's lifetime.

In fact it would be a good idea to keep a backup copy somewhere (for example in ~/.libreoffice/3/user/backup) for all recently used documents. If you keep several versions, that would be a great feature because it would mitigate user-mistakes (most deletions are caused by user-mistakes).

I am a software developer myself and while it may be technically true that OpenOffice 2.4 also contains this bug (it's a *BUG*, not an enhancement proposal), it does not seem to appear as often. Maybe it's the combination with my NFS-setup (which has sometimes a delay of a few seconds because it has to spin up) or whatever, but 2.4 didn't do that for years, while 3.5 did it within a week after installation. In any case it's unacceptable.

So please use fsync. Most Linux-installation which will install LibreOffice >3.5 will be using ext4 anyway. (But as I said, even I as an ext3 user would prefer a frozen GUI to dataloss any day of the week.)

[Michael Meeks (michael-meeks)]

pushed fix to master.

[Libreoffice-bugs (libreoffice-bugs)]

Michael Meeks committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d3192948fe968fc4d6a8ec0e6fda232f265b3c4c

fdo#40607 - osl_syncFile having written, and avoid doing that on start

[Libreoffice-bugs (libreoffice-bugs)]

Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c6e22c0fc0cc4ce1508f8401c4b0c14fc89df942&g=libreoffice-3-5

fdo#40607 - osl_syncFile having written, and avoid doing that on start

It will be available in LibreOffice 3.5.2.

[Michael Meeks (michael-meeks)]

Cor reports some significant slowdowns at first-ever-start it seems we're doing a load of fsyncs on that code-path (140 or so) - but it'd be good to get some strace -ttt -f data from him on that.

[Björn Michaelsen (bjoern-michaelsen)]

fix commited on upstream master and backported to 3-5:
http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=c6e22c0fc0cc4ce1508f8401c4b0c14fc89df942

[Björn Michaelsen (bjoern-michaelsen)]

backported to packaging with:
http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=commitdiff;h=5384155d746ac839af7b3ff311d20f6c7e77bfad

(will be fixed in upstream 3.5.2)

[Launchpad Janitor (janitor)]

This bug was fixed in the package libreoffice - 1:3.5.1-1ubuntu4

---------------
libreoffice (1:3.5.1-1ubuntu4) precise; urgency=low

  * version bump for bug 930217

libreoffice (1:3.5.1-1ubuntu3) precise-proposed; urgency=low

  * fix typo in control.in

libreoffice (1:3.5.1-1ubuntu2) precise-proposed; urgency=low

  * call fsync on write (LP: #817326)
  * add a few conflicts for defusing the old -common dpkg-trigger
    around interfering (LP: #916291)
  * its com.sun.star.sdb.RowSet, not sdbc neither sbd
  * never let users save in /tmp by default (LP: #905355)
 -- Bjoern Michaelsen <email address hidden> Fri, 30 Mar 2012 14:34:41 +0200

[Libreoffice-z (libreoffice-z)]

I added Fix submitter as assignee because this will ease queries and bug tracking.

[Eduard Hasenleithner (eduard-hasenleithner)]

Is there a chance that this will get an SRU for lucid?

[sibidiba (sibidiba)]

A recovery option worked for me:

http://stackoverflow.com/questions/22542527/recovering-odt-file-using-scalpel

Scalpel and foremost are forensic tools which can recover from any kind of filesystem by greping all bytes on the disk. Works well for FAT USB stick...

[Angel Garcia (angarciaba)]

This bug has returned to live. LibreOffice 4.2.8.2 Compilation Id. 420m0 (build:2), with autobackup active each 15 min. Running on Ubuntu 14.04 LTS. ext4 hard disk.

I opened a .doc, (previously created by LOW), made modifications (6 hour session) while continuously saving (each 5 minutes or so). Then I saved and closed the document and turned off the computer. When I came back, the file .doc was untouched as if any changes were made.
I looked for similar files in all the hard disk (grep), I looked in the libreoffice backup directory (empty) and also I ran scalpel, at no avail.

[Angel Garcia (angarciaba)]

However I also have to discard hardware problems or even viruses, no matter how improbable be.

[Freshie (freshie)]

Apparently the LibreOffice bug described in the previous posts is still in operation on version 5.3. The other day, while I was working in a document in LibreOffice 5.3 a split-second outage made my computer shut down. The 'save auto-recovery information every' field was selected and set at 10-minutes interval. I also and saved the document more often. Power outages had happened to me dozens of times while working on OpenOffice and other word processors, and the file recovery process was always capable of recovering most of the work. When I turned the computer on again the usual recovery window appeared (like on other word processors) informing me of the recovery process. I followed the steps carefully and expected to lose only a few minutes of work, but when the document opened there were several pages of work missing. It was almost the same document I had opened hours ago. Several hours of hard work just gone. There wasn't any backup of temp file or anything to retrieve an earlier version. I couldn't believe that happened.

It wasn't a virus at all or anything other than a LibreOffice serious defect.

That clearly shows that LibreOffice recovery function doesn't work, and attempting 'recovery' will only cause a large loss of data, even data saved manually while the document is open. This is a very serious bug, and in striking contrast with the most popular word processors, which, in my experience, always recover all data saved before the interval set in load/save options.