Bug 93394 - Data lost in docx saved document after hibernation and using Crashplan
Summary: Data lost in docx saved document after hibernation and using Crashplan
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.1.3.2 release
Hardware: Other macOS (All)
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-08-12 17:16 UTC by Eric Hanson
Modified: 2016-10-10 10:27 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
78k text document saved as Word docx in LibreOffice which appears mostly gone (72.64 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2015-08-12 17:16 UTC, Eric Hanson
Details
screen shot of how Crashplan logged multiple version during failed restoration (706.08 KB, image/png)
2015-08-12 17:18 UTC, Eric Hanson
Details
restored doc file from midday 08/10 with all the pages written to that point (55.19 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2015-08-12 17:20 UTC, Eric Hanson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Hanson 2015-08-12 17:16:41 UTC
Created attachment 117867 [details]
78k text document saved as Word docx in LibreOffice which appears mostly gone

I worked all day 08/10/15 on a docx file in LibreOffice, saving automatically and periodically by pressing save. Put Macbook to sleep, reopened and file had lost all but 3 pages of 70+ pages of document.

Went to Crashplan backups and every hour or so the backed up file grew noticeably from around 35k to around 70k, but retrieved files were also only 3 pages long. Crashplan's system is byzantine and their staff listens while customer follows complex instructions. Nothing worked. Crashplan blamed Libre Office and me. I ended support call and tried doing some restores myself and found that a file from around 2PM had close to 45 pages. 

I found it worked to drag the restored file to Pages instead of Libre Office and rename the file that had 44 pages. When I tried to open this renamed file in LibreOffice it told me it was corrupted and couldn't be opened. So i reopened it in Pages, copied the entire text and pasted it into a new LibreOffice document and renamed and resaved it in two copies, also in ODT.

Is it possible for anyone at Libre Office to explain why these 78k files are empty of 90% of the text content? 

Is it possible for anyone at Libre Office to restore the text in files that appear to have content that won't open?

Still perplexed and angry that what appears to be a long and growing series of text files on Crashplan's server turn out to have 78k of nothing.
Comment 1 Eric Hanson 2015-08-12 17:18:58 UTC
Created attachment 117868 [details]
screen shot of how Crashplan logged multiple version during failed restoration

I'm getting confused as the Crashplan restored versions are renamed and seem to be filed in new identically named silos.
Comment 2 Eric Hanson 2015-08-12 17:20:52 UTC
Created attachment 117869 [details]
restored doc file from midday 08/10 with all the pages written to that point

I also saved this file as ODT
Comment 3 Alex Thurgood 2015-08-13 06:49:15 UTC
@Eric : sounds like either LibreOffice or Crashplan don't know how to manage file conflicts in multiple versions with each other. This may not entirely be LibreOffice's fault, although it could also be the hibernation system of OSX that has screwed up the file (which kind of rings a bell from way back).

This is bugzilla, for bugs, not a user support forum. We do not recover corrupted files here. You might have better luck on the user mailing list or LibreOffice forum.

Without having exact steps as to how to reproduce the problem, confirming the bug report is going to be difficult.

LibreOffice can create its own backups "in memory" with the appropriately ticked option, but this is not particularly robust. If this option was activated, you might be able to find some of the LO backup files in your user profile folder (somewhere in /Users/<username>/Library/Application Support/LibreOffice. Otherwise, files, when open are stored in /tmp. Sometimes it is possible to retrieve data from such temporary files.
Comment 4 Alex Thurgood 2015-08-13 06:52:14 UTC
At present, there are too many variables in the scenario to be able to reproduce. I have no idea what Crashplan is, nor do I intend to use it. The only thing I could possibly try is an export to docx then hibernate the Mac, e.g. by closing the lid. However, to date, I can not recall having encountered a problem with this in current versions of LibreOffice. You are using and end of life version of LibreOffice, so you could perhaps try updating to a newer one if that is possible for you.
Comment 5 Alex Thurgood 2015-08-13 06:58:14 UTC
If I attempt to open your docx file, in LibreOffice 5.0.0.5, I get the following error :

rreur de format de fichier à la position 
SAXParseException: '[word/document.xml line 2]: Opening and ending tag mismatch: hyperlink line 0 and p
', Stream 'word/document.xml', Line 2, Column 25399(row,col).

which indicates that the XML has been corrupted. As both docx and LO use XML based content, it should be possible for you to unzip this file and try and find the missing/incorrect tag at the position indicated in the message, and correct it, resave, and then try and re-open, bearing in mind that the XML processor will stop at the first error it encounters, so there may be others in the file.

Perhaps there is a tool you can find that will allow you to run the XML through a checker that has some form of autocorrect mechanism for docx files.
Comment 6 Alex Thurgood 2015-08-18 09:21:53 UTC
Please provide detailed steps as to how to reproduce the problem, otherwise we have no hope of confirming the bug with regard to hibernation / resume / suspend.

Does the problem occur with native ODF documents, or only when working with OfficeOpenXML ?

Setting to NEEDINFO
Comment 7 Xisco Faulí 2016-09-11 13:17:51 UTC Comment hidden (obsolete)
Comment 8 Xisco Faulí 2016-10-10 10:27:14 UTC
Dear Bug Submitter,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-20161010