The attached spreadsheet was created with LibreOffice 4.1.0.0.beta1 (build id: 410m0 (build: 0)), using Debian/experimental package. LibreOffice fails to open the document: Read-Error Format error discovered in the file in sub-document content.xml at 2,10046(row, col) xmllint --format content.xml outputs the following error multiple times: content.xml:2: parser error : Attribute office:currency redefined ency="EUR" office:value="92" calcext:value-type="currency" office:currency="EUR" From content.xml : <table:table-cell table:style-name="ce4" office:value-type="currency" office:currency="EUR" office:value="89" calcext:value-type="currency" office:currency="EUR"> ^
Already fixed with http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-1&id=d2ec94f0576af3f0675b171c74528cae735adef4
Thanks, marking as resolved then.
I'm seeing a similar issue with LO 4.1b2 on OS X 10.8.4: http://cl.ly/image/1j0h1y351B2i (the error is basically identical, just the number of the col differs). Re-opening.
*** Bug 65297 has been marked as a duplicate of this bug. ***
changing platform to "all" since now this is happening on Linux and OS X.
Example file attached here https://bugs.freedesktop.org/show_bug.cgi?id=65297 still produces said error with LO 4.1b2. Also setting to "Critical" since this means users cannot open their files. In my case I'm stuck with an important file I need to get some financial stuff done.
Users in my org got similar problem (specifically 2 times I've been called about that, both times it was LO 4.0.3). They are getting error message during saving, telling there was an "error saving file" (nothing specific). Saved file zip headers and CRC are corrupt. It can be partially recovered, short of contents.xml. In their settings, "Backup always" checked, but backup is corrupt either! So if they get this error during saving, the only way to save data is to copy everything to another document. If it hasn't been done, whole document is lost in non-recoverable way. That's very frustrating, and causes more and more users demand MSO installed.
Raising to "high" singe if data is lost this is imo more than "medium" importance.
This bug is already fixed as said in comment 1, and indeed it's reproducible with 4.1.0beta1 but not with 4.1.0.4. So changing back to RESOLVED FIXED. @James: It means that LO doesn't create such corrupted files anymore, but You can't except that LO will open your file, because your file is already *corrupted*.
*** Bug 68543 has been marked as a duplicate of this bug. ***
Should be reopened: I get repeatedly corrupted .ods files with duplicate tags in libreoffice calc 4.1.4.2. I have not found a specific editing action that triggers the corruption. I use two simple vba-macros, 'Conditional Format', shared documents. xmllint gives: content.xml:2: parser error : Attribute table:id redefined e:cell-content-change><table:cell-content-change table:id="ct82" table:id="ct83" ^ content.xml:2: parser error : Attribute table:id redefined e:cell-content-change><table:cell-content-change table:id="ct97" table:id="ct98" ^ content.xml:2: parser error : Attribute table:id redefined cell-content-change><table:cell-content-change table:id="ct111" table:id="ct112" ^ content.xml:2: parser error : Attribute table:id redefined cell-content-change><table:cell-content-change table:id="ct122" table:id="ct123" ^ content.xml:2: parser error : Attribute table:id redefined cell-content-change><table:cell-content-change table:id="ct130" table:id="ct131" ^ content.xml:2: parser error : Opening and ending tag mismatch: table-row line 2 and table-cell ffice:value="0" calcext:value-type="float"><text:p>0</text:p></table:table-cell> ^ content.xml:2: parser error : Opening and ending tag mismatch: table line 2 and table-row -cell><table:table-cell table:number-columns-repeated="1014"/></table:table-row> ^ content.xml:2: parser error : Opening and ending tag mismatch: spreadsheet line 2 and table s.E6"/></calcext:conditional-format></calcext:conditional-formats></table:table> ^ content.xml:2: parser error : Opening and ending tag mismatch: body line 2 and spreadsheet "true" table:orientation="column"/></table:database-ranges></office:spreadsheet> ^ content.xml:2: parser error : Opening and ending tag mismatch: document-content line 2 and body rientation="column"/></table:database-ranges></office:spreadsheet></office:body> ^ content.xml:2: parser error : Extra content at the end of the document rientation="column"/></table:database-ranges></office:spreadsheet></office:body> ^
@polzin: That's another problem. Please open a new bug for it.
Okay. I was now able to reproduce the problem. Probably, it's not worth opening a new bug, because the root was a VBA-macro doing an insert of a partial row with shifting of lines. This is forbidden in the GUI when tracking of changes is enabled, but the macro was able to do this and broke the content.xml. If you think it's valuable opening a bug, I will do it.
(In reply to comment #13) > Okay. I was now able to reproduce the problem. Probably, it's not worth > opening a new bug, because the root was a VBA-macro doing an insert of a > partial row with shifting of lines. This is forbidden in the GUI when > tracking of changes is enabled, but the macro was able to do this and broke > the content.xml. If you think it's valuable opening a bug, I will do it. While not familiar with this issue, I'm sure that LO shouldn't save corrupted files in any case.
*** Bug 73335 has been marked as a duplicate of this bug. ***
Confirmed its still available on Linux in 4.2.4 and 4.3 beta 2.
Confirmed in 4.2.5.2
(In reply to comment #17) > Confirmed in 4.2.5.2 What exactly confirmed? Did you still see the error from comment 0? (I guess you're talking about your Bug 80793? If so, it's not related to this one.) For anyone reading this bug: There are many reasons why a document might be corrupted, and it's a bad idea to handle them all in one bug. This one is fixed as indicated in comment 1. For any other case please open a new bug.