File unaccessible after edit - must modify xml to open

Today I received a homework file on which I worked yesterday, with corrections. I modified the file according to the corrections, and saved it. Everything went well, but after closing and trying to re-open the file, the following error appeared:

image description

Following the instructions here, I managed to salvage the file’s information, however it was stripped from its styles. When trying to re-apply the styles, the file would produce the same error messages.

I couldn’t understand what was causing the problem, but I believe it’s something to do with change tracking. If anyone can help me, so I can report a bug, I’d appreciate it. :slight_smile:

I created the file with the new LibreOffice My teacher added comments with version, and then I used my version of LO again, to modify the file while tracking changes. I’m using Linux Mint 17.1, 32-bit, and my teacher is using Windows 8.1 (I don’t know what architecture).
The file, both with the corruption and with the fix, can be found here.

Thanks in advance!

V4.4.0.3 is very “FRESH”. Why not keep 4.3.5 for “critical” work? If you are on windows, it’s very easy to have a second version in the PortableApps mode for testing, e.g.

I attempted to make the changes again with 4.3.5, and the exact same thing happened.

Since it’s homework piece, I don’t suppose you’d share the file so we can try to reproduce ?

I did indeed share it. It’s the link at the very end of the question. :slight_smile:

This was the “offender”:

<style:style office:name="__Annotation__1273_193379381714141414141514141414141414141414" office:name="__Annotation__1277_1933793817151615151515151515151515" office:name="__Annotation__1278_1933793817171515141414141415151515161716161616161616161616" office:name="__Annotation__1367_193379381716151515151516161616171817171717171717171717" style:name="Table1" style:family="table"><style:table-properties style:width="6.6903in" table:align="center"/></style:style>

I think I got it fixed: ProblemFileNoLongerBroken.odt

Editing with respect to the comment by @Amir below:

I don’t even know (and did not investigate now) if a <style:style ..../> tag may legally contain an office:name assignment. But as my XML syntax tool opted against that tag something must be wrong with it, I thought. I didn’t worry about the annotations themselves defined at a distance. I simply removed the 4 references to a named structure and left the clean-up to LibreOffice. No reference, no error, I guessed, and it worked.

If you worry about I can tell you the author (4 times the same), the times of creation, and the content for the four cases. I do not know if LibO uses the local system time for the purpose. The format is without the respective extension (ISO 8601). Suppose it’s global.

Yes, that seems to work. However, any further modification done to the file causes the problem to return. What does this code mean exactly? What is the root of the problem, so to speak?

I’m not a developer, and I never tried to analyse any part of the source code. From my wisdom I can, however tell you: It’s an error. Joking aside: Any software project the source code of is containing some million lines is prone to errors of different kinds. An old bug with hardly any effect on the surface may rise and become a problem if a reworked preparation for saving must be implemented to meet enhanced standards …Very fresh variants will suffer more …

Is there no way to isolate this problem to some components, then? Is it even worthwhile to report a bug with such little information?

I’m confident the bug will get fixed. Meanwhile use the same version as Mrs. E.Z. does.

Very well. Thank you for your effort. :slight_smile: