Libre Office cut off over half my doc

English
#1

I just spent a couple of hours editing a long doc, saving frequently, only to close, re-open, and see that all but the first 14 pages have been lost (I had to save in Docx to share will colleagues). I did some searching and found a thread from SEVEN YEARS AGO with people talking about how the program cuts off documents after HTML links: Lost most pages in document - #4 by petermau, which referenced this bug report from TEN YEARS AGO https://bugs.documentfoundation.org/show_bug.cgi?id=55143. I tried to follow the instructions, maybe I’m doing it wrong/I’m not super technical, but I have not been able to recover the missing pages in Libre, Word, or any other program. I tried re-saving in a bunch of different file formats and removing the relevant hyperlink. Does anyone have any other fixes or is maybe able to give additional instructions for re-packaging for someone who isn’t super technically literate?

I do not understand how this major bug has not been fixed after AN ACTUAL DECADE. This is going to be the reason I finally quit Libre and buy MS office. I can deal with the horrendous interface, but a bug that regularly discards large portions of files even when people are vigilant about saving, that the team has known about for ten years and has done nothing to fix, is absurd.

#2

The tdf#55143 that you mention is not “a major bug that has not been fixed after AN ACTUAL DECADE”. It tells clearly in its comment 19, that the symptoms experienced initially were tested, and no data loss happened in later versions.

If you see something similar, it may be unpleasant; and you may use whatever software you feel safe - that’s wise; but please don’t make wrong assumptions based on similarity of your problem. Sometimes very different problems may create similar symptoms.

Very recently, I myself discovered something that could very well be also your problem (tdf#149996); and what I find ironical is that that problem appeared exactly because of fixing a very similar, but still different problem. And that fix could itself be related to tdf#55143.

Things are complex when you talk about office suites and external file formats. Also, one must realize that support for external file formats like DOCX will never be perfect in LibreOffice, and the best is to use its native file formats whenever possible for work and storage, and only export to external formats when required to send to someone - keeping the original work in the native format.

1 Like
#3

A lot of water has flown under the bridge since that time. Notably, memory options have been removed and the fix based on tweaking memory configuration is no longer valid.

So instead of ranting and complaining about pending bugs, give factual information so that we can understand the issue and spot it: OS name, LO version and save format (OK, you told .docx) and formatting method (styling vs. direct formatting, though I think you endup in direct formatting because of limitation in DOCX format).
If possible, attach a sample document showing the bad behaviour.

Meanwhile, change your operational procedure for a more reliable one:

  • work in native format and save .odt
  • when you need to exchange with colleagues, and only then, export to .docx or even .pdf
    Be aware thet the conversion is not a bijection and some formatting will be lost through it.
  • if you need to merge feed back from your colleagues, enter it manually into your .odt
    To make things easier, enable “Track Changes” before exporting the document so that you see immediately what was changed.


PS:
We are mere users, like you, no developers and not affiliated in any way with The Document Foundation. So yelling about unfixed bug is useless and rather rude if you don’t get the gist of this site.

1 Like
#4

Thanks for your reply. And, to be clear, I obvi didn’t mean to rant at other users, I understand this is a peer forum, I was just mad and wanted the actual DF development team to see it. In my head, I was ranting with the other users, not at them, if that makes sense. I get that it’s a free service and doesn’t owe me anything, but I have donated over the years and I do rely on it to get my work done and seeing (what appeared to be, at least) a really old, serious bug that chewed up a couple of hours of work was really frustrating. I had no choice but to use Docx for this, it was sent to me in that format and I had to keep the formatting when sending back the edits, which I know is not best practice for Libre, but it did not occur to me that most of my work could just disappear. Anyway, thanks again for responding and sorry if it sounded like I was yelling at y’all, wasn’t my intention, just wanted to try to call attention to what seems like a serious issue that has been affecting people for a long time (it could be that it’s a new bug that just happens to look exactly like the old bug, in which case my bad).

I’m just re-doing it in Word because it needs to get done quickly and I feel like I’ve already spent too much time trying to recover, so I won’t ask for more help for myself. If others are reading this and want to try to fix the bug, my OS is Monterey 12.2.1, running 7.4.3.2 Libre, I think only direct formatting (I’m not sure if the version that was sent to me had stylizing, but if so, it didn’t appear in Libre), I can’t attach the doc because it contains privileged info unfortunately but I’m happy to answer other questions.

#5

Note that this specific sort of problems almost always allows to restore 100% (unless one opens the cut off file, and saves it then in that cut off state). The problem at save time in these cases is that something is written in a wrong place (the details of what gets misplaced where and why is the essence of each separate bug; but the end result is similar); and that breaks reading at that place - but the data is still there, and allows to fix it manually. Just the file itself is needed.

#6

If the original file came from M$ Word, be sure everything is direct formatted. And this adds to the issue by creating a real mess upon opening the file in Writer. Between illiteracy of common users (on a formatting methodlogical point of view) and coarse limitations on DOCX side, the best advice is: use the same application as the one having created the document when you can. And always save in this application native format.

#7

Offtopic.

It is always amazing to me how asymmetrical the situation is. There is MS Office with its OOXML native file format; and there’s LibreOffice with its ODF. I wonder how long will it take to anyone using MS Office, if they suddenly decide to use the ODF that is supported by MS Office, as their main format, before they see that completely ruining their work. I bet, it will be almost instantly - because you know, descent support of an external file format is something almost impossible for anyone like MS.

At the same time, LibreOffice offers that level of support for the external format, that some people (not OP here, I read about “it was sent me” part) work with that format as their main format (most often when they share with other users; but believe me, there’s lots of those who don’t know anything about formats, and just decided to use DOCX because they heard about DOCX) in their everyday work, and only learn about problems when those problems arise - sometimes months and even years later.

And indeed, the imperfect support of the external format on LibreOffice side is of course much less forgivable sin.

#8

On every load your document is converted to LibreOffice internal format and with every save translated back to docx. There is no internal handling of documents in foreign formats.
.
So you actually can save after the initial load as .odt and export at the end to .docx. All you “loose” is the constant translations.
.
If you really wan’t to preserve .docx “unchanged” you should use the same M$-Office as your peers. Otherwise: Test all features you are using…

1 Like

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.